jrfonseca / drmingw

Postmortem debugging tools for MinGW.
GNU Lesser General Public License v2.1
273 stars 53 forks source link

SetLogFileNameA not working #18

Closed renatosilva closed 9 years ago

renatosilva commented 9 years ago

I can't make the new SetLogFileNameA function work. I'm trying to call it like this:

if ((module = LoadLibraryA(exchndl_path))) {
    typedef BOOL (APIENTRY* LPFNSETLOGFILE)(const char*);
    LPFNSETLOGFILE MySetLog = (LPFNSETLOGFILE) GetProcAddress(module, "SetLogFileNameA");
    char logfile[MAX_PATH];

    if (MySetLog && (GetTempPathA(sizeof(logfile), logfile) != 0)) {
        strcat(logfile, "pidgin.RPT");
        MySetLog(logfile);
    }
}

Starting with revision 318048b I get:

Program received signal SIGILL, Illegal instruction.
0x68cc1635 in ?? () from C:\ProgramFiles.x86\Pidgin++\libssp-0.dll
jrfonseca commented 9 years ago

That's odd. Your code looks OK. And matches the unit test for that entrypoint.

It's also weird that it's crashing inside libssp-0.dll. This is for some sort of stack protection.

How are you building this code? What's the gcc/g++ version?

renatosilva commented 9 years ago

Interesting, log file is actually set successfully and reports this libssp crash just like GDB above. Debug output from the application also mentions stack smashing detected. I build both the application and Dr. MinGW with MSYS2/MinGW-w64. Here are my compiler versions:

gcc.exe (Rev5, Built by MSYS2 project) 4.9.2
g++.exe (Rev5, Built by MSYS2 project) 4.9.2
jrfonseca commented 9 years ago

Yes, I suspected that much -- something is causing a buffer overflow, but I don't thing it is due to the APIENTRY calling convention.

You built Dr.MinGW? So you are not using my binaries? (I hope you're not building exchdnl.c with -D_UNICODE ....)

In that case, does mingw32-make check work?

renatosilva commented 9 years ago

I have found the solution, there was another function pointer definition in the code that also needed to be updated. I confirm that SetLogFileNameA works for me.