[EDGY] firefox crashed [@vfprintf] [@vasprintf] -- libvlc.so.0

Thank you for submitting this report.

Johan, can you describe how the crash has been produced? Is it reproducible?

Thanks in advance.

Retrace done:
...
 #4 0xb2dc111c in ?? () from /usr/lib/libvlc.so.0
 #5 0xbf786764 in ?? ()
 #6 0xfbad8000 in ?? ()
 #7 0x0a534900 in ?? ()
 #8 0x0a534900 in ?? ()
 #9 0x0a534900 in ?? ()
 #10 0x0a534900 in ?? ()
 #11 0xb7879ff4 in ?? () from /lib/tls/i686/cmov/libc.so.6
 #12 0x00000016 in ?? ()
 #13 0x00000016 in ?? ()
 #14 0xbf7866e0 in ?? ()
...

Tagging as mt-confirm for further processing

Not a very informative retrace. Awaiting reporter's feedback.

Retraced Thread Stacktrace

Unforturnately I don't have much in terms of repro instructions.

The following link may have been involved though:
http://tant.webblogg.se/1174562408_svenottos_korstg.html

Try scrolling up / down and see if it helps, but I'm really hoping you'll be able to trace this from the crash dump.

I have answered the question as well as I could. Feel free to change the tags again if you feel they need changing.

Thank you for the bug report. Could you please try to obtain a backtrace by following the instructions on https://wiki.ubuntu.com/MozillaTeam/Bugs or attach the crash report located in /var/crash.
This will greatly aid us in tracking down your problem.

John, the crash report from /var/crash is the first attachment to this bug, named "Crash file".

If you're able to get some information out of it, that would awesome!

Johan i did not ask for the crash report i asked if you can follow the instructions to obtain a backtrace. the backtrace should give us more info than your crash report since we dont know what extensions/addons/plugins and so on that you use. Since the crash report didnt retrace well it would be alot of help if you can follow those instructions to reproduce it.

I'll see what I can do about debugging this manually.

John, is there a bug report about the failed retrace? I'd like to subscribe myself to that one.

most failed retraces are due to non ubuntu extenstions or packages that we cant build -dbg or -dbgsym packages. there are a few 6 or so bug reports i filed against apport and around 100 in total but i dont have numbers atm, you should beable to go to https://launchpad.net/ubuntu/+source/apport/+bugs to see some of them. there should also be some if you replace apport with apport-retrace.

Leaving needs info.

I just reported bug 95504 about the failed retrace.

Hilario, I CCed you on that report as well since you're the one who ran it.

apport-retrace seems to have problems with libc and libpthread (see bug 95504).

I'm assuming apport-retrace uses gdb as unwinder.

The crash seems to be somewhere in libc.

The wiki instructions tell me to use gdb to find that crash.

If gdb cannot find its way inside of libc when you're running it at your end, it probably won't be able to do that when I'm running it at my end either.

So I'll just wait for the unwinding-libc-doesn't-work issue to be fixed. Then you should be able to retrace the crash file included in this bug report and get a proper stack trace.

If I've missed anything in my reasoning above, please let me know and I'll make an attempt at following the wiki instructions.

more than likely the cause of the non informitive retraced stack is due to not haveing -dbg nor -dbgsym for non ubuntu apps like flash

If the non informative stack trace was because of foreign libs, at least the name of the foreign lib should be seen in the stack trace.

Now we have lines like...
#0 0xb7785e09 in vfprintf () from /lib/tls/i686/cmov/libc.so.6

... which is obviously inside of libc, but takes no parameters according to the unwinder. Comparing that to the vfprintf() man page shows that this is wrong.

Or can you point to an example in the stack traces that shows where foreign libraries without debug info is being used?

Note that all the ?? frames are most probably places where the unwinder has already gotten lost and is unwinding garbage.

On Sun, Mar 25, 2007 at 12:47:49AM -0000, Johan Walles wrote:
> If the non informative stack trace was because of foreign libs, at least
> the name of the foreign lib should be seen in the stack trace.

I think the retrace will not see the foreign lib if it is not
available.

>
> Now we have lines like...
> #0 0xb7785e09 in vfprintf () from /lib/tls/i686/cmov/libc.so.6
>
> ... which is obviously inside of libc, but takes no parameters according
> to the unwinder. Comparing that to the vfprintf() man page shows that
> this is wrong.

this might be a different issue, e.g. not properly installed libc
debug symbols, however the rest of the stack is still worthless.

However, I wonder why we have not libvlc.so debug symbols.

Anyway, all this discussion is fruitless, as we still have no usable
stacktrace.

Either producing a stacktrace directly on your system might help, or
even better getting a testcase to reproduce.

 - Alexander

Edgy doesnt have alot of -dbgsym at all due to apport being so new to ubuntu and iirc it was started mid release more important things like (upstart) i believe took 1st place. as for this being a libc issue that is not correct, the problem being lack of -dbgsym packages to use for retrace.

I'm not saying libc is buggy, I'm saying the crash happened inside of libc. That can happen if somebody passes bogus parameters to vfprintf() for example, without libc being buggy.

Generally you can trust #0 frames to at least be in the correct library, since the stack unwinder hasn't had to walk anywhere for frame #0. If the unwinder has problems with frame #0 it may or may not be able to walk out of it and end up in the correct place. So all bets are off for the following frames if one frame is problematic.

To find problems with crashes inside of libc the unwinder needs to be able to unwind libc code. The unwinder doesn't seem to be able to do that in this case. You most probably have -dbgsym packages for libc, so it'd surprize me if the problem is that those are missing. Your retracing thingy needs to tell the unwinder about those though, and the unwinder needs to be able to use them, and one of those things may not work very well here.

I made a small test case (attached) to see what happens when trying to look at a core file when a library in which we have crashed is missing:

(gdb) bt
#0 0xb7f47503 in ?? ()
[...]

Compare that to what you get from the core file:
#0 0xb7785e09 in vfprintf () from /lib/tls/i686/cmov/libc.so.6

Doing this on a Debian Testing system (at home now, only running Ubuntu at work), so YMMV. Test script is attached though, so you can verify on your system.

Anyway, as long as you guys are unable to unwind the libc code involved in this crash I don't expect to be able to do any better :-(.

NB:
 #2 0xb2ccc60f in __msg_Create () from /usr/lib/libvlc.so.0

Did you have the vlc packages installed when retracing this? It seems that vlc used an invalid sprintf() or similar statement which led to this crash.

Martin:
(edgy_chroot)root@hjmf:/home/hjmf$ dpkg -l | grep vlc
ii libvlc0 0.8.6.release-0ubuntu1~edgy1 multimedia player and streamer library
ii mozilla-plugin-vlc 0.8.6.release-0ubuntu1~edgy1 multimedia plugin for web browsers based on VLC
ii mozilla-plugin-vlc-dbgsym 0.8.6.release-0ubuntu1~edgy1 debug symbols for package mozilla-plugin-vlc
ii vlc 0.8.6.release-0ubuntu1~edgy1 multimedia player and streamer
ii vlc-nox 0.8.6.release-0ubuntu1~edgy1 multimedia player and streamer (without X support)

Unfortunately, your crash report does not contain the information that we need in order to process this bug properly. If you ever manage to capture another crash report, or find instructions on how to reproduce this crash reliably, don't hesitate to open a *new* bug. Thanks for your contribution,

 - Alexander

Thank you Johan Walles for your report,

This particular issue has already been reported as bug #78725 [1]
(MASTER firefox crashed [@vfprintf] ... -- libvlc.so.0).

Please feel free to add any other information you might consider to be related
to this particular issue (e.g. a test case) either to [1] or [2].

As the original reporter you'll be informed by email of all comments or changes
that affects either this report or the Master Bug (bug #78725 [1]).
You can unsubscribe [3] to stop receiving this mailing at any time.

And, of course, please don't doubt to report any other crashes/issues you might
find in the future.

Further information can be found at [4].

Again, thank you.

[1] https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/78725
[2] https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/94753
[3] https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/78725/+subscribe
[4] https://wiki.ubuntu.com/MozillaTeam/Bugs