Re: Immediate crash upon calling PL_initialize (Win32)

Hi Katain,

On 02/19/2014 12:58 AM, Kaitain Jones wrote:
> I've got SWI working pretty much as expected in a small Win32 console app.
> But now I'm trying to to integrate it into our much more heavyweight
> app/codebase (still Win32) and am hitting a wall as soon as I try to
> initialize the system, that takes the whole app down. It compiles and
> links, and seems happy with the DLLs on startup. But it seems to be the
> very first attempt to call into the libswipl DLL that causes the
> explosion...anyone have any ideas as to how to begin diagnosing the problem?

Ideally using a C debugger :-)  That is a bit of an issue mixing gcc and
MSVC though.  I don't have much experience here as I'm not faced with 
this combination.  Second best is to recompile the system and add
-DO_DEBUG to the COFLAGS in Makefile (after configuration).  Then you
can enable/disable debug topics using -d topic1,topic2,...  You find the
things you can enable by scanning for DEBUG(<topic>, ...).  Old topics
are numeric and enable anything with a lower number.  New topics are
named, typically msg_* for messages and chk_* for additional (expensive)
consistency checks.

If the stack is right, this suggests _free() is the culprit, indicating
some form of memory corruption.

Multi-threaded/single threaded should not be an issue.  There might be
an issue if you initialize from a thread other than the main thread. At
least, you probably need to initialize in a thread that won't die before
the end of the process.  I think you can initialize from a dll, but it
might be worthwhile to try from the main executable.  My first move 
would be to call PL_initialise() right at the start.  Also make sure 
that the argument vector is permanent (as well as the strings inside it).

	Hope this helps

		--- Jan


>
> ntdll.dll!_LdrpCallInitRoutine@16()  + 0x14 bytes
>    ntdll.dll!_LdrShutdownProcess@0()  + 0x141 bytes
>    ntdll.dll!_RtlExitUserProcess@4()  + 0x74 bytes
>    kernel32.dll!768a79c5()
>    msvcrt.dll!___crtExitProcess()  + 0x17 bytes
>    msvcrt.dll!__cinit()  + 0x13c8 bytes
>    msvcrt.dll!_exit()  + 0x11 bytes
>    libswipl.dll!6d28b85b()
>    libswipl.dll!6d301a61()
>    msvcrt.dll!_free()  + 0x39 bytes
>    libswipl.dll!6d334a00()
>    libswipl.dll!6d334f3a()
>    libswipl.dll!6d301c10()
>    msvcrt.dll!_free()  + 0x39 bytes
>> libswipl.dll!6d334a00()
>    t3.mll!InitializerInstructions::ExecutePrologStartup()  Line 250 + 0xd
> bytes C++
>    t3.mll!PrologBridge::InitializeNewPrologSession()  Line 291 C++
>    t3.mll!PrologBridge::InitializeNewPrologSession(const
> InitializerInstructions & instructions={...})  Line 298 C++
>    t3.mll!InitPrologForStory(char * targetFile=0x07b4348c)  Line 1500 + 0x13
> bytes C++
>
> I was trying to see if I could repro the problem in the smaller (and
> single-threaded) console app, but I haven't been able to do so. I was about
> to embark on a slightly tedious expedition to add elements gradually to the
> working app to push it ever closer to the state of the larger app and
> (hopefully) find the point where failure is triggered, but wondered if
> anyone had some handle on what was likely to be going on here (or a more
> informed path of suggested investigation).
>
> To add extra details:
>
> ExecutePrologStartup()
>
> calls
>
> PL_initialise(nCommands, plav)
>
> with nCommands = 1 and plav having "libswipl.dll" in cell 0 and NULL in
> cell 1. (In the working console app, it seems not to matter what I pass as
> the plav argument; I can put a nonsense word in and the default/fallback
> logic seems to be fine.)
>
> KJ
> -------------- next part --------------
> HTML attachment scrubbed and removed
> _______________________________________________
> SWI-Prolog mailing list
> [email protected]
> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>