[haiku-bugs] [Haiku] #8430: [kernel] mplayer segfaults in a loop
- From: "diver" <trac@xxxxxxxxxxxx>
- Date: Fri, 30 Mar 2012 13:01:25 -0000
#8430: [kernel] mplayer segfaults in a loop
---------------------------+------------------------------
Reporter: diver | Owner: bonefish
Type: bug | Status: new
Priority: normal | Milestone: R1
Component: System/Kernel | Version: R1/Development
Keywords: | Blocked By:
Blocking: | Has a Patch: 0
Platform: All |
---------------------------+------------------------------
This is hrev43901 gcc2hybrid.
[http://dl.dropbox.com/u/15787359/mplayer.zip mplayer binary] (8MB)
After running '''mplayer !smb://share/video.avi''' (it doesn't matter if
video.avi actually exists or not!) mplayer crashes. After that
GUI and cursor becomes extremely sluggish and unresponsive. [[BR]][[BR]]
ProcessController shows that mplayer uses 50% of cpu, the other 50% is
used by '''syslog_daemon'''. [[BR]] I had changed it's priority from
'''normal ![10]''' to '''lowest active ![1]''' and GUI with cursor became
normal again.
I can see in Tracker that syslog gets constantly overwritten.
The following message repeats zillion times in syslog:
{{{
vm_soft_fault: va 0x0 not covered by area in address space
vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x0,
ip 0x0, write 0, user 1, thread 0x313
vm_page_fault: thread "mplayer" (787) in team "mplayer" (787) tried to
read address 0x0, ip 0x0 ("???" +0x0)
}}}
Then I debugged mplayer thread from ProcessController:
{{{
[...]
[Switching to team /boot/apps/Mplayer/mplayer smb://share/video.avi (299)
thread mplayer (299)]
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x03cd09ee in ucnv_close () from
/boot/system/lib/gcc4/libicuuc.so.48.1.1
#2 0x03de1e67 in
BPrivate::Libroot::ICUThreadLocalStorageValue::~ICUThreadLocalStorageValue
() from /boot/system/lib/gcc4/libroot-addon-icu.so
#3 0x03ddf0e9 in
BPrivate::Libroot::ICULocaleBackend::_DestroyThreadLocalStorageValue ()
from /boot/system/lib/gcc4/libroot-addon-icu.so
#4 0x018bb892 in __pthread_key_call_destructors () from
/boot/system/lib/gcc4/libroot.so
#5 0x018bad18 in __pthread_destroy_thread () from
/boot/system/lib/gcc4/libroot.so
#6 0x018ae222 in _thread_do_exit_work () from
/boot/system/lib/gcc4/libroot.so
#7 0x0190f0b0 in exit () from /boot/system/lib/gcc4/libroot.so
#8 0x0030ab39 in rm_osd_msg ()
[...]
#14 0x00b81e4f in _tevent_req_notify_callback ()
[...]
#30 0x01000000 in ff_codec_caf_tags ()
[...]
#43 0x00eabcd1 in tdb_allocate ()
#44 0x03de1e67 in
BPrivate::Libroot::ICUThreadLocalStorageValue::~ICUThreadLocalStorageValue
() from /boot/system/lib/gcc4/libroot-addon-icu.so
#45 0x03ddf0e9 in
BPrivate::Libroot::ICULocaleBackend::_DestroyThreadLocalStorageValue ()
from /boot/system/lib/gcc4/libroot-addon-icu.so
#46 0x018bb892 in __pthread_key_call_destructors () from
/boot/system/lib/gcc4/libroot.so
#47 0x018bad18 in __pthread_destroy_thread () from
/boot/system/lib/gcc4/libroot.so
#48 0x018ae222 in _thread_do_exit_work () from
/boot/system/lib/gcc4/libroot.so
#49 0x0190f0b0 in exit () from /boot/system/lib/gcc4/libroot.so
#50 0x0030c0a2 in exit_player_with_rc ()
#51 0x012be558 in ?? ()
(gdb)
}}}
mplayer binary is from 20.05.2011.[[BR]]
Some pointers from DeadYak:
{{{
DeadYak looks like it's trapping segfaults
DeadYak that might explain the issue, if it's doing that in a loop it's
going to be nailing the VM like crazy
DeadYak file that as a kernel bug and assign to bonefish
please...including screenshots
DeadYak looks like mplayer installs a segfault handler and then something
else goes wrong
DeadYak possibly during thread cleanup
DeadYak but right now it looks more like a VM bug
DeadYak or a combination of a design issue in the VM + bad behavior
somewhere
DeadYak also, if that behavior doesn't happen in older revs, it'd be
interesting to know when it started
DeadYak I suspect this isn't a new problem though
}}}
--
Ticket URL: <http://dev.haiku-os.org/ticket/8430>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
