[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash-commit] [bug #37077] segfault in[a85b5000+47000

From: Paul Menzel
Subject: [Gnash-commit] [bug #37077] segfault in[a85b5000+47000]
Date: Sat, 27 Oct 2012 11:52:19 +0000
User-agent: Mozilla/5.0 (X11; Linux) AppleWebKit/535.22 (KHTML, like Gecko) Chrome/18.0.1025.133 Safari/535.22 Midori/0.4

Follow-up Comment #5, bug #37077 (project gnash):

Am Samstag, den 27.10.2012, 11:10 +0000 schrieb Bastiaan Jacques:
Follow-up Comment #4, bug #37077 (project gnash):
> > 1. What version of Midori do you run? I am using a self-build from latest
> Git.
> midori-0.4.6-1.fc17.x86_64
> > 2. Did you open like 20 tabs from Phoronix. That triggers this
> > usually in my case.
> Yes, lots of Flash activity seems to make it more likely to happen.
Sorry, if you have mentioned it already. But it does not segfault for you,
does it?

> 4. Any idea what I can do to provide more information to analyze the stack
> > corruption.
> Not really. When faced with memory corruption problems I normally use
> to find where the problem starts, but running Midori in Valgrind leads to
> early segfault on my system before we get to any Flash content.

There seem to be some packages for Fedora with 0.4.7. Maybe that works

I tried that today and it did not segfault for me.

G_SLICE=always-malloc valgrind --track-origins=yes --leak-check=full
--num-callers=50 midori --plain
But even after an hour nothing of the site was displayed and nothing related
to `gnash` was mentioned in its output.

> 5. Should not the library/plugin return an error instead of segfaulting?
> Absolutely. It is possible though that the segfault is ultimately caused by
> Midori due to a bug in their NPAPI implementation, though.

That might be true too.


Reply to this item at:


  Nachricht gesendet von/durch Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]