Mail Archives: djgpp-workers/2001/04/22/19:54:22
Hello.
At 08:39 PM 04/21/2001 +0300, you wrote:
>> Date: Fri, 20 Apr 2001 14:52:51 +0200 (MET DST)
>> From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
>>
>> > >at descriptor tables and register contents more easily), it refused to
>> > >crash...
>> >
>> > Which crash is that, the SIGSEGV from the core dumper or the
>> > _expected_ crash?
>>
>> FSDB doesn't catch the SIGABRT from the abort(), it seems. In FSDB, I can
>> run the program with <F9> and it just finishes. SIGABRT prints its
>> message, the core dumper prints (core dumped), and dumps the core file,
>> and that's that.
>
>I might be missing something, but since SIGABRT is not a real crash,
>just a simulated one, why did you expect FSDB to ``catch'' it?
Try generating a floating-point exception like divzero instead. Anyway,
that's the way it behaves under GDB for me. The program crashes as expected
when debugged under GDB but when run alone it crashes with a SIGSEGV
supposedly generated by the core dumper code.
>> Finding 0xdeadbeef in the core file is not a problem at all, AFAICS. The
>> only problem it hints at is that if the program had not been run in
>> 0xdeadbeef mode, these same areas would have been completely
>> uninitialized, and might not ever have been mapped in before the core
>> dumper wants to dump their content to disk.
>
>They are not initialized, that's true. But they _must_ have been
>mapped into the program's address space, because that's how they got
>their 0xdeadbeef signature: this is done by sbrk when it allocates the
>memory from the OS. Since sbrk touches those pages when it sets them
>to 0xdeadbeef, the system pages in that memory.
>
>Or am I missing something?
It should be expected to find deadbeef in the core file if this is the
case. What we should check now are pointers deadbeef in the core dumper
code. Since the SIGSEGV seems to disappear when the program is run inside a
debugger, I am at a loss as to what to do to examine this further...
Hans, could you please redir the CFTB output to a file? I'll need to to see
those, thanks.
>> Question to the gurus: is on-the-fly allocation of previously unmapped
>> pages ('holes') supposed to work, while the client is inside an exception
>> handler?
>
>I think you are mixing unmapped memory with memory that is not paged
>in. Untouched memory might be not paged in, but it _must_ be mapped
>into the program's address space. That mapping happens when sbrk
>requests memory from the DPMI host. In other words, all the memory
>regions whose handles we have in __djgpp_memory_handle_list[] _must_
>be mapped into the program's address space at all times.
>
>Anyway, referencing an address which doesn't belong to one of the
>pages mapped into the program's address space will _always_ cause a
>Page Fault.
Let's not forget that this problem _does_not_ happen on pure DOS with
CWSDPMI R5. Eli, is it possible for the __djgpp_memory_handle_list to
become corrupt prior to an exception?
nimrod_a_abing
--------------
+========================================+
| Home page: www.geocities.com/n_abing |
+========================================+
"Tinimbang ka ngunit kulang."
If you understand that phrase, i-email mo'ko. ;-)
- Raw text -