Mail Archives: djgpp/2003/07/21/23:39:52
> Date: Mon, 21 Jul 2003 18:32:35 +0200
> From: Peter Claessens <peter DOT claessens AT psy DOT kuleuven DOT ac DOT be>
>
> C:\src\dots2002>dotread -cl
> Exiting due to signal SIGSEGV
> Page fault at eip=000bd61d, error=0006
> eax=000000af ebx=000bd724 ecx=00000010 edx=00001757 esi=000bd724
> edi=031c17dc
> ebp=00000fbc esp=00000fbc program=<**UNKNOWN**>
> cs: sel=00a7 base=84830000 limit=03242fff
> ds: sel=00af base=84830000 limit=03242fff
> es: sel=00af base=84830000 limit=03242fff
> fs: sel=0087 base=00015ee0 limit=0000ffff
> gs: sel=00bf base=00000000 limit=0010ffff
> ss: sel=03cb invalid
> App stack: [03243000..031c3000] Exceptn stack: [00168718..001667d8]
>
> Call frame traceback EIPs:
> 0x000bd61d
>
> Notice the bizarre 'program' value. This is the same run under GDB:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x000ca7e1 in _doprnt ()
> (gdb) backtrace
> #0 0x000ca7e1 in _doprnt ()
> Cannot access memory at address 0x804
Sounds like somehow it tries to print too early, when the run-time
environment is not yet set up. Weird.
Anyway, this probably means you should for now drop the idea of
setting DEBUG to a non-zero value.
> Do you think it would be a good or a bad idea to try the malloc_debug
> functions in the nmalloc package that I found under the alpha
> distribution info for djdev?
It cannot hurt to use the malloc_debug package. Try setting the debug
level to the maximum, and see what it tells you. Also, call the
function that checks the heap integrity in a few places, and see where
it starts complaining.
> Sorry that I channel all this material through the djgpp mailing
> list.
Nothing to be sorry about, this is the appropriate place for such
discussions.
- Raw text -