Memory mapped segments in a core dump

  • Follow


I'm debugging a core dump on Solaris 9 with dbx.  Warnings like this
appear three times as dbx is starting:

	dbx: internal warning: writable memory segment 0xfeb80000[491520] of size 0 in core

These segments correspond to memory mapped files.  Does this mean that
those segments were excluded when the core dump was created, or that
the memory mapping failed somehow?  Is there a way to ensure that those
segments appear in the dump?


-- 
-Gary Mills-    -Unix Support-    -U of M Academic Computing and Networking-
0
Reply Gary 2/13/2006 2:15:03 AM

In article <dsoq37$ssb$1@canopus.cc.umanitoba.ca>,
	Gary Mills <mills@cc.umanitoba.ca> writes:
> I'm debugging a core dump on Solaris 9 with dbx.  Warnings like this
> appear three times as dbx is starting:
> 
> 	dbx: internal warning: writable memory segment 0xfeb80000[491520] of size 0 in core
> 
> These segments correspond to memory mapped files.  Does this mean that
> those segments were excluded when the core dump was created, or that
> the memory mapping failed somehow?  Is there a way to ensure that those
> segments appear in the dump?

In Solaris 10, it's an option in coreadm. Haven't got
a Solaris 9 system handy to check if it was in that too.

-- 
Andrew Gabriel
0
Reply andrew 2/13/2006 6:31:37 AM


In <43f027c9$0$1169$5a6aecb4@news.aaisp.net.uk> andrew@cucumber.demon.co.uk (Andrew Gabriel) writes:

>In article <dsoq37$ssb$1@canopus.cc.umanitoba.ca>,
>	Gary Mills <mills@cc.umanitoba.ca> writes:
>> I'm debugging a core dump on Solaris 9 with dbx.  Warnings like this
>> appear three times as dbx is starting:
>> 
>> 	dbx: internal warning: writable memory segment 0xfeb80000[491520] of size 0 in core
>> 
>> These segments correspond to memory mapped files.  Does this mean that
>> those segments were excluded when the core dump was created, or that
>> the memory mapping failed somehow?  Is there a way to ensure that those
>> segments appear in the dump?

>In Solaris 10, it's an option in coreadm. Haven't got
>a Solaris 9 system handy to check if it was in that too.

Judging by the lack of:

	init core file content: default

in the Solaris 9 coreadm output, I'd say there's no such option
there.

-- 
-Gary Mills-    -Unix Support-    -U of M Academic Computing and Networking-
0
Reply Gary 2/13/2006 2:40:39 PM

In article <dsq5p7$prs$1@canopus.cc.umanitoba.ca>,
	Gary Mills <mills@cc.umanitoba.ca> writes:
> In <43f027c9$0$1169$5a6aecb4@news.aaisp.net.uk> andrew@cucumber.demon.co.uk (Andrew Gabriel) writes:
>>In Solaris 10, it's an option in coreadm. Haven't got
>>a Solaris 9 system handy to check if it was in that too.
> 
> Judging by the lack of:
> 
> 	init core file content: default
> 
> in the Solaris 9 coreadm output, I'd say there's no such option
> there.

I've got a hazy recollection of the history of this issue, having
submitted a bug on it in the very distant past.

Back around Solaris 2.4 / 2.5 era, shared memory wasn't dumped.
I was with an ISV at that time maintaining an application which
used shared memory. If one of the processes crashed, I added the
shared memory onto the end of the dump. I tried to use libelf to
update the coredump segment headers to reflect the shared memory
segments were there, but I couldn't get that to work (even just
opening and closing the coredump with libelf corrupted it). So
I updated the segment headers with my own code, and then dbx
would work. I raised a bug with Sun on the shared memory missing
from coredumps.

Sometime around Solaris 2.6, 7 or 8, Sun fixed this issue.
However, the fix had other side effects. IIRC, it dumped all
mmaped areas including mmaped files, which was regarded as a bug.
The fix for dumping mmaped files was to stop coredumps including
shared memory, and we were back to square one;-)

Looks like the proper fix, making it configurable, appears in
Solaris 10.

-- 
Andrew Gabriel
0
Reply andrew 2/13/2006 9:11:52 PM

3 Replies
449 Views

(page loaded in 0.068 seconds)

Similiar Articles:













7/24/2012 9:03:22 AM


Reply: