i loaded up Xsun under libumem with debugging enabled.
when i tried to run mozilla Xsun core dumped.
the core file is attached.
--
> ::status
debugging core file of Xsun.bin (32-bit) from mcescher
file: /usr/openwin/bin/Xsun.bin
initial argv: /usr/openwin/bin/Xsun.bin :0 -nobanner -dev /dev/fb1 defdepth 24 defclass TruCo
threading model: native threads
status: process terminated by SIGSEGV (Segmentation Fault)
> $C0
ffbfe030 libumem.so.1`print_sym+0x50()
ffbfe0b8 libumem.so.1`print_stacktrace+0x50()
ffbfe318 libumem.so.1`umem_err_recoverable+0x58()
ffbfe378 libumem.so.1`process_free+0x104()
ffbfe3d8 ddxSUNWjfb.so.1`ifbCloseScreen+0x90()
ffbfe438 libmpg_psr.so.1`mpgCloseScreen+0x34()
ffbfe498 libovl.so.1`ovlCloseScreen+0x34()
ffbfe4f8 libmpg_psr.so.1`widCloseScreen+0x34()
ffbfe558 cmapCloseScreen+0x24()
ffbfe5b8 ddxSUNWjfb.so.1`closeScreenWrapper+0x3c()
ffbfe618 PictureCloseScreen+0x24()
ffbfe678 CursorCloseScreen+0x2c()
ffbfe6d8 AbortDDX+0xb0()
ffbfe758 sunSignalHandler+4()
ffbfe7b8 libc.so.1`__sighndlr+0xc()
ffbfe818 libc.so.1`call_user_handler+0x3e4()
ffbfebe0 libxinput.so.1`SizeDeviceInfo+0x10()
ffbfec40 libxinput.so.1`ProcXListInputDevices+0xb4()
ffbfecd8 Dispatch+0x188()
ffbffd40 main+0x8cc()
ffbffdb0 _start+0x108()
> umem_error_buffer/s
libumem.so.1`umem_error_buffer:
libumem.so.1`umem_error_buffer: free(4df3f0): double-free or invalid buffer
stack trace:
libumem.so.1'?? (0xff36b2ec)
--
here's an email from xxxxx@xxxxx.COM
--
Date: Tue, 13 Dec 2005 16:13:12 -0800
Subject: Bug 6341101: Xsun tries to free invalid memory from a signal handler
Hi Ed,
From the stack trace in the bug report, it shows Xserver died already. It encounters
the invalid free on the way down when it is trying to clean up. The "AbortDDX" shows
the server died of other reasons. So the invalid free may not be the cause of why
Xsun died. I've attached a ddx with the invalid free commented out. Could you try it
out see if you get a different stack trace?
--
i tried out the new binary died in a similar manner:
--
> $C0
ffbfe030 libumem.so.1`print_sym+0x50()
ffbfe0b8 libumem.so.1`print_stacktrace+0x50()
ffbfe318 libumem.so.1`umem_err_recoverable+0x58()
ffbfe378 libumem.so.1`process_free+0x104()
ffbfe3d8 0xfec69e00()
ffbfe438 libmpg_psr.so.1`mpgCloseScreen+0x34()
ffbfe498 libovl.so.1`ovlCloseScreen+0x34()
ffbfe4f8 libmpg_psr.so.1`widCloseScreen+0x34()
ffbfe558 cmapCloseScreen+0x24()
ffbfe5b8 0xfec9fc0c()
ffbfe618 PictureCloseScreen+0x24()
ffbfe678 CursorCloseScreen+0x2c()
ffbfe6d8 AbortDDX+0xb0()
ffbfe758 sunSignalHandler+4()
ffbfe7b8 libc.so.1`__sighndlr+0xc()
ffbfe818 libc.so.1`call_user_handler+0x3e4()
ffbfebe0 libxinput.so.1`SizeDeviceInfo+0x10()
ffbfec40 libxinput.so.1`ProcXListInputDevices+0xb4()
ffbfecd8 Dispatch+0x188()
ffbffd40 main+0x8cc()
ffbffdb0 _start+0x108()
> umem_error_buffer/s
libumem.so.1`umem_error_buffer:
libumem.so.1`umem_error_buffer: free(4f13f0): double-free or invalid buffer
stack trace:
libumem.so.1'?? (0xff36b2ec)
--
both the binary and the new core file are attached. (they both have
a "1." prefix.)
Since it dies the same way with free commented out in ddx, this proves the invalid free is not in ddx. Transfer back to server group.
well, it doesn't actually look like you commented out the free() calls
in the stacktrace above since the ddx module is still the one
calling into libumem.
--
> $C0
ffbfe030 libumem.so.1`print_sym+0x50()
ffbfe0b8 libumem.so.1`print_stacktrace+0x50()
ffbfe318 libumem.so.1`umem_err_recoverable+0x58()
ffbfe378 libumem.so.1`process_free+0x104()
ffbfe3d8 0xfec69e00()
...
> ::mappings
BASE LIMIT SIZE NAME
...
fec60000 feca2000 42000 /usr/openwin/server/modules/ddxSUNWjfb.so.1
--
To run Xsun under libumem i did the following:
--
mv /usr/openwin/bin/Xsun /usr/openwin/bin/Xsun.bin
cat >> /usr/openwin/bin/Xsun <<-EOF
#!/bin/sh
LD_PRELOAD=libumem.so UMEM_DEBUG=default UMEM_LOGGING=transaction
export LD_PRELOAD UMEM_DEBUG UMEM_LOGGING
exec /usr/openwin/bin/Xsun.bin "$@"
EOF
chmod a+x /usr/openwin/bin/Xsun
--
the following comments were added to the justification:
--
This bug is only reproduceable with fvwm2 window manager.
The invalid memory free is not the reason why Xsun died.
--
questions:
1) what happens if you attempt to reproduce this problem with other window
managers?
2) What is the reason that Xsun died?
i never saw any answers to my questions above.
regardless, it seems to me that that ddxSUNWjfb.so it still broken and
should be fixed. this bug is preventing me from analyzing other Xsun
bugs. specifically:
6341109 Xsun is leaking memory
hence i'm returning it's priority to a p2.
Work Around
N/A
Comments
Bug is verifed on X_112 build.
Here is the test process, pls correct me if it is wrong.
1. Install X_112 on latest SNV
/net/paravon/export/x-re/pkgs/X_NV_milestone/sparc/B112
2. To run Xsun under libumem i did the following:
--
mv /usr/openwin/bin/Xsun /usr/openwin/bin/Xsun.bin
cat >> /usr/openwin/bin/Xsun <<-EOF
#!/bin/sh
LD_PRELOAD=libumem.so UMEM_DEBUG=default UMEM_LOGGING=transaction
export LD_PRELOAD UMEM_DEBUG UMEM_LOGGING
exec /usr/openwin/bin/Xsun.bin "$@"
EOF
chmod a+x /usr/openwin/bin/Xsun
--
3. Reboot the machine and login CDE/GNOME.
4. Start web browser.
The bug reporter said when starting mozilla, Xsun core. But mozilla is replaced by firefox on latest SNV. So I started firefox to test this bug.
Ensure that Xsun doesn't core dump.