why functions from fftw dll are not working? - gcc

I have the following piece of code:
#include <stdio.h>
#include "S:\fftw\fftw3.h"
int main()
{
fftw_complex* in;
fftw_complex* out;
fftw_plan p;
in = (fftw_complex*)fftw_malloc(sizeof(fftw_complex));
out = (fftw_complex*)fftw_malloc(sizeof(fftw_complex));
p = fftw_plan_dft_1d(1, in, out, FFTW_FORWARD, FFTW_ESTIMATE);
fftw_execute(p);
fftw_destroy_plan(p);
fftw_free(in);
fftw_free(out);
printf("test!\n");
return 0;
}
when I compile with
gcc -g .\test.c -o test S:\fftw\libfftw3-3.dll
and execute the generated
test.exe
it does execute without errors but doesn't show the printf message. If I use gdb and simply run the program there, no matter what I try, gdb freezes and just gives the following output:
Starting program: S:\Notes\C\numerics\src\test.exe
[New Thread 8244.0x2a80]
[New Thread 8244.0x1668]
[New Thread 8244.0x4790]
[Thread 8244.0x1668 exited with code 3221225781]
This happens from the exact moment I call a function that has to be linked to the .dll, everything works fine if I don't.
I am using
gcc.exe (x86_64-win32-sjlj-rev0, Built by MinGW-W64 project) 8.1.0
and
GNU gdb (GDB) 8.1, This GDB was configured as "x86_64-w64-mingw32".
from MingW64 and I simply downloaded the fftw .dlls from the mainpage.
Can anyone help? I have absolutely no clue what this is about.

From the debugger, you can see the exit code 3221225781, which is 0xC0000135 in hexadecimal. If you look it up on MS-ERREF, it means "STATUS_DLL_NOT_FOUND" and "{Unable To Locate Component} This application has failed to start because %hs was not found. Reinstalling the application might fix this problem."
Likely, the application can't find libfftw3-3.dll. You need to either put it in the same directory of the executable, or in one of the other DLL search paths.
If you start the application from explorer (double clicking), it should also tell you that message, including the DLL name it couldn't find if you continue to get the same exit code.

Related

Issue when debugging with gdb after compiling with the MSYS2 MinGW-w64 gcc (crtexe.c, No such file or directory)

I'm having this "issue" with gcc and gdb, which by itself isn't a real problem but it still annoys me and I want to understand why it's happening and how to solve it. First I want to apologize because English is not my native language.
tl;dr: When I debug a file compiled with the MSYS2 MinGW-w64 gcc and I get to the last line of main and click 'Step over' (on VS code) or type the 'next' command (running gdb on the shell) I get an error indicating that the file 'crtexe.c' cannot be opened or be found. It doesn't cause me any trouble but it's annoying. Also, it doesn't happen when the official MinGW-w64 gcc compiler is used instead.
To put you in context, I'm doing the Harvard's CS50 course but I always want to dig deeper and end up spending much more time in topics don't covered by the course itself, so now I'm on Windows 10 with MSYS2, Mingw-w64, and VS Code installed. In the beginning, I started only with MinGW-w64 that I downloaded from the official website but then I realized that gcc was outdated and that installing libraries was quite complicated. So after some Google searches, I discarded the 'official' MinGW-w64 and ended up with MSYS2 and the MinGW-w64 built by them. I had the task.json, launch.json, and c_cpp_properties.json from VS Code already set up so I only changed the paths to gcc and gdb of MSYS2 and I was good to go.
But now I've noticed an error that wasn't happening before with the 'official' version of MinGW-w64. When I'm debugging a program (as simple as a 'helloworld') and I get to the last line of main (the final curly bracket) and click 'Step Over', this error message appears in VS Code:
I need to press 'Step Over' again (and receive the same error message again) two more times to finally end the program.
At first, I thought it was VS Code fault so I ran gdb directly from the shell and stepped over the code with the 'next' command, and I got the same error at the end:
(gdb) next
Hello world!6 }
(gdb) next
__tmainCRTStartup ()
at D:/mingwbuild/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:337
337 D:/mingwbuild/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c: No such file or
directory.
(gdb) next
338 in D:/mingwbuild/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c
(gdb) next
[Thread 4232.0x1a94 exited with code 0]
[Inferior 1 (process 4232) exited normally]
That made me think it was gdb the one causing the problem. But finally, after testing with both gcc and gdb from both the official MinGW-w64 and MSYS2's MinGW-w64 I concluded that the one with the issue was MSYS2 MinGW-w64 gcc. I can compile with the official mingw-w64 gcc and debug with gdb of msys2 and it works fine. But in reverse, if I compile with MSYS2 MinGW-w64 gcc and debug with the official MinGW-w64 gdb, the problem appears again.
When I compile using the official MinGW-w64 gcc and then debug it, the final gdb lines are these:
Hello world!6 }
(gdb) next
0x00000000004013c7 in __tmainCRTStartup ()
(gdb) next
Single stepping until exit from function __tmainCRTStartup,
which has no line number information.
[Thread 9436.0x1748 exited with code 0]
[Inferior 1 (process 9436) exited normally]
which doesn't translate into an error message in VS Code.
As I understand, that function (__tmainCRTStartup) is the one that starts every C program and also kills the process when it's over. I know I can simply ignore that error. But I hate error messages hehe. Besides, why if I'm stepping over the code, the debugger tries to step into that function's source code? I'd understand if I'm trying to step into, but that's not the case. Why is this happening and what can I do to fix it? (besides clicking 'Continue' instead of 'Step Over' when I'm at the end of main).
Thank you!

Compiling with MinGW gcc Makes windows defender suspect of virus [duplicate]

I had compiled a simple hello world program in C with the MinGW compiler using the command line. As it had finished compiling, windows defender popped up and detected a virus (Trojan:Win32/Fuery.C!cl).
#include <stdio.h>
#include <stdlib.h>
int main() {
printf("Hello World");
return 0;
}
https://imgur.com/a/05yDjw5
I had taken action on this (Removed) as windows defender suggested, but when I compile again the same happened, multiple times.
I had downloaded an AntiVirus (Malwarebytes) and scanned my whole system and it detected some registry key errors, but not this.
I've tried compiling C++ files too, but windows defender did not detect any virus there. This only happens when I compile in C.
I've also tried checking the compiled executable at VirusTotal.
https://www.virustotal.com/gui/file/476d47215dad80db49c9fd508ab5e10e5aeb5b623248ca156830a28b70affe5f/detection
I tried CodeBlock's MinGW compiler and 0 engines detected it. (Same C file)
https://www.virustotal.com/gui/file/8ba4b0fa24b1b6b69152acce2353fcca8447bbecbfc4e5ec48d33cc75d94f2f1/detection
EDIT: I deleted the path variable of C:/MinGW and added CodeBlock's MinGW compiler. I then used the command line to compile the same C file again and had uploaded the .exe file to VirusTotal. This time, 0 engines detected. So I have come to the conclusion that, the MinGW compiler that I had installed was creating this problem.
https://www.virustotal.com/gui/file/34d383f6c09f897d8c9a44ed0e7850574320e50fdf439eeb1f06705fdcc95386/detection
I don't know why this happens. Is there a malware in my computer that affects my C programs or is this a false detection?
There is no malware, it is a false positive. The executable generated by your version of MinGW looks very similar to a particular virus.
To avoid the problem, add the directory where you build your code to the list of exclusion in the antivirus.
Also consider using mingw-w64 instead of mingw.org .
I came across with the same problem, compiler tdm gcc v9.2.
The following compilation triggers a warning (kaspersky).
gcc temp.c -o temp.exe
The following does not
gcc -O3 temp.c -o temp.exe
Where temp.c is
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
int main() {
int a, b;
scanf("%d %d", &a, &b);
printf("mod %4d, %4d is %4d\n", a, b, a%b);
return 0;
}
The same code with g++ passes the test with both compilations. The antivirus software does not detect the same virus elsewhere but only in temp.exe (first compilation).
I may have solved my problem.
This is what I did: I removed the PATH Variable of C:\MinGW and added CodeBlock's MinGW compiler (CodeBlocks/MinGW/bin). I used the command line to compile the same C file, and had uploaded the .exe to VirusTotal. No engines detected this file!
https://www.virustotal.com/gui/file/34d383f6c09f897d8c9a44ed0e7850574320e50fdf439eeb1f06705fdcc95386/detection
So I have come to a conclusion that, MinGW was the compiler that was causing this problem. I have removed it.
However, I am not quite sure if this problem is FULLY solved. There is still a possibility of malware affecting my executable (or perhaps not). I cannot be sure.
If anyone has any answers, please comment or answer
I ran into this after installing MinGW on 01-08-20(dd-mm-yy).
For me it was also Windows Defender, the way to - hopefully temporarily- get rid of this is to add an exception for the folder your compilation output will reside in.
The Microsoft website states these steps to add an exclusion:
Go to Start > Settings > Update & Security > Windows Security > Virus & threat protection.
Under Virus & threat protection settings, select Manage settings, and then under Exclusions, select Add or remove exclusions
I had a similar problem. I figured out that the following dll was missing: mingw32-libmingwex-dll. Once I installed it via "MinGW Installation Package", I didn't have the problem anymore.
I hope this can help others.
Since you wrote that program and you know it isn't actually a Trojan, it's obviously a false positive. You should submit the file to them at https://www.microsoft.com/wdsi/filesubmission so they can figure out why it's triggering the false positive and fix it. (If it happens with everything you compile, just sending them one will suffice.) In the meantime, you should add an exclusion to Windows Defender for the folder that you compile your executables in.

Debugging a simple ARM 64-bit executable causes internal error in GDB

I wrote a simple C program to print hello world. Then I ran it through
aarch64-linux-gnu-gcc -ohello hello.c -static -g3
gdb-multiarch hello
After this, I run and gdb encounters an internal error:
Reading symbols from hello...done.
(gdb) r
Starting program: /home/gt/hello
/build/gdb-GT4MLW/gdb-8.1/gdb/i387-tdep.c:592: internal-error: void i387_supply_fxsave(regcache*, int, const void*): Assertion `tdep->st0_regnum >= I386_ST0_REGNUM' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
Here's the output of file hello:
hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.7.0, BuildID[sha1]=a...b, with debug_info, not stripped
This is my hello.c:
#include<stdio.h>
int main(){
printf("hello world");
return 0;
}
What am I doing wrong? What else do I need to do? I am running Ubuntu 18.04 on an x86_64 machine.
When I use gdb hello, I am unable to use breakpoints, I get this error:
Reading symbols from hello...done.
(gdb) break 4
Breakpoint 1 at 0x400404: file hello.c, line 4.
(gdb) r
Starting program: /home/gt/hello
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x400404
(gdb)
I am following the guide given on this page under the first section.
In order to run and debug your AArch64 executable, you (in general) need to run it on an AArch64 machine, or in an AArch64 emulator.
You might have some setup where qemu more or less transparently emulates aarch64 binaries for you - but that doesn't work quite as transparently for the debugger. In general you can run the debugger on one machine, connected over a network to a debugging server on a different machine, allowing you to debug a process running on the machine with the debugging server.
The guide you linked shows how to set up qemu to allow it to transparently emulate binaries as you execute them. That guide only shows executing, not debugging, but it has got a link "Debugging using GDB" that points to https://ubuntuforums.org/showthread.php?t=2010979&s=096fb05dbd59acbfc8542b71f4b590db&p=12061325#post12061325, where it is explained how to debug a process which executes within qemu emulation. This essentially amounts to the same remote debugging with a debugging server as I mentioned above.
The essential bits of this post is this:
# In a terminal
$ qemu-arm-static -g 10101 ./hello
# In a new terminal
$ gdb-multiarch
(gdb) target remote :10101
Remote debugging using :10101
[New Remote target]
[Switching to Remote target]

GDB Failed to find frame when using BOOST library with GCC 4.9 on OSX

My problem is when debugging from Eclipse a program that uses Boost (even pure header) then the GDB debugger is unable to locate frame base for the function being trace into.
Please note that except this, the program works like a charm in debug and release mode. The problem is only for debugging and inspecting source code refering to Boost.
Please not also that the problem only affects OSX Yosemit.
The issue is that I can't see the value of the local variables. Below is the message I have in the "(x)= Variables" window of Eclipse :
Failed to execute MI command:
-data-evaluate-expression result
Error message from debugger back end:
Could not find the frame base for "main()".
The code is as simple as :
#include <boost/regex.hpp>
#include <iostream>
int main() {
int result = 1;
boost::regex reExpression("[a-z]+");
std::cout << "!!!Hello World !!!" << std::endl;
result ++;
cout << " Result = " << result << "\n";
return result;
}
The program is compiled using the command :
g++ -v -o -g bin/Essai-MACOS-Debug src/Essai.cpp -I/opt/local/include /opt/local/lib/libboost_regex-mt.a
If you remove the reference to Boost.Regex then everything is ok. I can inspect the value of the local variable result.
More interesting: I built a library with a single function relying on Boost, and call that function from main(). It happens that can inspect the code in main() and have the value of main's local variable but when I came inside the library's function, the one now referring to boost then again I can't see the local variables of that function.
So it seems that as soon as a source file is referring to Boost, GDB get confused.
I have installed GCC 4.9, GDB 7.7 and Boost 1.57 using MacPort on OSX Yosemit.
I've compile Boost from source with MacPort in order to use GCC instead of GCC using the command :
sudo port install -ns boost config.compiler=macport-gcc-4.9
I also tried with a version of Boost I compiled myself and I did have the same issue.
Does anyone knows about this problem ?
EDIT:
I've compiled and installed the last GDB version from sources (7.9) and have the same issue described here than with the 7.7.1 provided by MacPorts.

After setting a breakpoint in Qt, gdb says: "Error accessing memory address"

I wrote a very simple Qt program here:
int main(int argc, char* argv[])
{
QApplication app(argc, argv);
QTableView table(&frame);
table.resize(100, 100);
table.show();
return app.exec();
}
And when I try to set a breakpoint where the table gets clicked, I get this error from gdb:
(gdb) symbol-file /usr/lib/libQtGui.so.4.4.3.debug
Load new symbol table from "/usr/lib/libQtGui.so.4.4.3.debug"? (y or n) y
Reading symbols from /usr/lib/libQtGui.so.4.4.3.debug...done.
(gdb) br 'QAbstractItemView::clicked(QModelIndex const&)'
Breakpoint 1 at 0x5fc660: file .moc/release-shared/moc_qabstractitemview.cpp, line 313.
(gdb) run
Starting program: ./qt-test
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x5fc660: Input/output error.
Does anyone know why the breakpoint can't be inserted?
Don't use the gdb command symbol-file to load external symbols. The breakpoint addresses will be wrong since they're not relocated.
Instead, put a breakpoint in main, run the program, and then set your breakpoint:
gdb ./program
GNU gdb 6.8-debian blah blah blah
(gdb) br main
Breakpoint 1 at 0x80489c1
(gdb) run
Starting program: ./program
Breakpoint 1, 0x080489c1 in main ()
(gdb) br 'QAbstractItemView::clicked(QModelIndex const&)'
Breakpoint 2 at 0xb7d24664
(gdb) continue
Continuing.
Then make your breakpoint happen.
Make sure to specify the parameter list in the function you want to set a breakpoint in, without the names of those parameters, just their types.
The actual error:
Error accessing memory address 0x5fc660: Input/output error.
Can be caused by 32/64 bit mixups. Check, for example, that you didn't attach to a 32-bit binary with a 64-bit process' ID, or vice versa.
If you want to automatically break in main without setting a breakpoint you can also use the start command.
If you need to provide any arguments to the program you can use:
start argument1 argument2
OK for me I got this when building with mingw-w64 (native or cross compiler).
I'm not sure what the exact problem was, but if I build it using gcc mingw-w64 i686-5.1.0-posix-sjlj-rt_v4-rev0 then it creates (finally) debuggable builds. Otherwise
(gdb) break main
...
(gdb) r
...
Cannot insert breakpoint 1.
Cannot access memory at address 0x42445c
<process basically hangs>
message 19 times out of 20, though sometimes it did actually work (very rarely).
gdb 7.8.1 and 7.9.1 seemed to be able to debug the created exe. So it's probably not the version of gdb that makes a difference.
My current theory/suspect is either it was the version of gcc or possibly the sljl vs. dwarf2 "aspect" to the compiler [?] (i686-492-posix-dwarf-rt_v3-rev1 didn't work, and cross compiling with some form of gcc 4.9.2 didn't either). Didn't try other versions of gcc.
update: newer gcc (5.1.0) but cross compiling I still got this failure. The cause in this case turned out to be a dependency library that my build (FFmpeg) was using by linking against (libgme in this case) which is exporting a few errant "shared" symbols (when I am building a static executable). Because of this, "shared" builds brake (https://trac.ffmpeg.org/ticket/282) and somehow it screws up gdb as well. For instance possibly linking against SDL can do this to you as well. My thought is possibly an ld bug [?]

Resources