Mail Archives: djgpp/2012/11/11/14:52:56
Am 11.11.2012 19:49, schrieb Eli Zaretskii:
>> Date: Sun, 11 Nov 2012 18:42:34 +0100
>> From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
>>
>> I have tried to compile a simple "hello world" like program. I have used MSDOS 6.22
>> together with DOSLFN 0.41 (used options ~- t+; this means that no numeric tail
>> will be created). I have used djdev204, gcc472b, bnu223b and CWSDPMI r7 without
>> activated swap file. The system has 64 MB. The program crashes with the
>> following stack trace:
>>
>> Stack Fault at eip=1902d; flags=3293
>> eax=11000000 ebx=00000000 ecx=00000000 edx=00000000 esi=4f575c3a edi=4407712f
>> ebp=415c4b52 esp=00000781 cs=e7 ds=ef es=ef fs=cf gs=0 ss=cf error=0000
>>
>>
>> It makes no difference if I use gcc471b and bnu222br4. It crashes in the same
>> way. If I try to debug the program, I get the following output:
>>
>> GNU gdb (GDB) 7.5
>> [snip]
>> Reading symbols from d:/work/a.exe...Dwarf Error: wrong version in compilation
>> unit header (is 0, should be 2, 3, or 4) [in module d:/work/a.exe]
>> (gdb) q
> Does GDB say that even if you remove DOSLFN, reboot, and then try
> debugging the program? If so, I'd suspect file I/O functions that
> somehow write corrupted data to the executable.
Yes, GDB says the same even if I remove DOSLFN and reboot the system.
Also the program continues crashing if I reemove DOSLFN and reboot the
system. The only way to get a program that does not crash and that can
be debuged with GDB is to recompile the code with DOSLFN deinstalled.
> One way to dig into this would be to run objdump on the binary
> compiled with DOSLFN, then on the same program compiled without
> DOSLFN, and compare the results.
>
> Once you've established that file I/O under DOSLFN is the problem, I'd
> try disabling the LFN DOS calls in functions like _write and see if
> that helps. Or maybe diff the sources of v2.04 against v2.03, and see
> which functions had changes in the LFN parts -- this could give you
> ideas what functions could trigger a bug in DOSLFN.
>
> Yes, it's a large job, sorry.
>
Yes, I will follow this strategy, but it make take same time until I will have fixed this
Regards,
Juan M. Guerrero
- Raw text -