Ludovic,
On 10/24/2014 11:47 PM, Rebecca N. Palmer wrote:
If it is that, the attached should fix it, but since I've never had this
problem myself I can't test it.
Could you please try this patch? I'd like to get some indication that it
actually fixes the issue, before asking for a freeze
Markus Wanner writes:
On 10/24/2014 11:47 PM, Rebecca N. Palmer wrote:
If it is that, the attached should fix it, but since I've never had this
problem myself I can't test it.
Could you please try this patch? I'd like to get some indication that
it actually fixes the issue, before asking for
On 10/27/2014 11:26 AM, Ludovic Brenta wrote:
Not until next weekend unfortunately, and then again I might not be able
to compile everything needed and do the testing, for lack of available
time. If you provide precompiled .deb packages on some web site, that
would expedite the testing; I
Rebecca, do you think there is a way to trigger this bug with certainty?
Even if that means modifying the sources to create an artificial trigger
for the bug?
It happens when naGC_swapfree finds that the Nasal dead list is full, so
we can make it more likely by reducing that limit:
Rebecca N. Palmer wrote:
With this, gdb --args fgfs --aircraft=b1900d --airport=NZNV and
pressing 'v' a few times reliably triggers it, allowing me to confirm
that the patch works.
Wow that was more than I hoped for. Is there still a need for me to
test Markus' package?
Thanks both for
Control: tags -1 upstream patch
I have now tried this patch, and while I can't tell if it fixes the
problem (as I never had it), it at least doesn't appear to break
anything else.
No comment from upstream on this particular patch, only a general
concern that other multithreading bugs might
I think I know what's wrong here: it's not two actual threads waiting
for each other, it's the inner and outer Nasal levels of thread 1, that
think they're separate threads when they're not.
If it is that, the attached should fix it, but since I've never had this
problem myself I can't test
Happened again after I pressed 'x' multiple times; in a Seneca II.
When I attached the debugger, sound stopped; when I typed cont in the
debugger, sound resumed. This suggests that thread 5 is not part of the
deadlock; but we already knew that, didn't we ? :)
--
Ludovic Brenta.
(gdb) thread
And it happened again while I was in level flight in a Beechcraft 1900D:
(gdb) thread apply all bt full
Thread 7 (Thread 0x7fa2b8ccd700 (LWP 8911)):
#0 0x7fa2c4a730b0 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#1
The deadlock occurred again on me after I crashed a SenecaII in the sea
west of New Zealand; since the deadlock occurred with a Beechcraft 1900D
before, the aircraft type seems not to be the culprit. Also I was not
cycling through views when the deadlock occurred; I pressed another key
which I
A quick test with --aircraft=b1900d --airport=EDDR and cycling through
the views didn't reproduce this, but given its intermittent nature that
doesn't prove anything.
Please install the debug symbols (apt-get install
libsimgearcore3.0.0-dbg libsimgearscene3.0.0-dbg) and re-run your trace
Package: flightgear
Version: 3.0.0-2
Severity: important
On several occasions while flying the Beechcraft 1900D, FlightGear
entered a deadlock; the screen would no longer refresh, CPU usage would
drop to 0% and FlightGear would no longer respond to any input. I
attached a debugger and found
12 matches
Mail list logo
