Tue 10 Jul 2007 03:43:50 PM UTC, comment #11:
Alright, found the bug. Nothing to do with key handling this time (the assertion failure).
See bug #20436 for that. This one is closed
|
Tue 10 Jul 2007 02:19:07 PM UTC, comment #10:
About the assertion failure, reproducible in the same way with both OLD and NEW key listening designs. Here's the assertion:
button on_event onKeyDown
gnash: server/button_character_instance.cpp:362: virtual bool gnash::button_character_instance::on_event(const gnash::event_id&): Assertion `parent' failed.
How to reproduce:
Click buttons and press keys so to advance till the "village" is shown (with the superimposed text). AT that point just press a key.
|
Tue 10 Jul 2007 02:08:24 PM UTC, comment #9:
I confirm the segfault is fixed (was already fixed by keeping the objects alive for the GC, with my commit of yesterday - can you confirm ?). Your removal should reduce the "keep growing" problem.
Still, I don't understand what would happen if the KeyListener was there due to a clip handler, not a user defined one. In this case the remove-Key_listener should NOT really remove it, right ?
BTW, now there's a new problem (an assertion failure).
|
Tue 10 Jul 2007 12:29:14 PM UTC, comment #8:
No segfault now.
I removed the key listener from the listeners container when they destructed. movie_root::remove_key_listener() just unregistered the listener before.
I'll do more tests tomorrow. "make check" passed.
|
Tue 10 Jul 2007 02:23:46 AM UTC, comment #7:
Mmm.. I'd think yes, loaded characters should NEVER be collected.
I'd be interested in knowing more about this case (GC deletes chars for which isUnloaded() returns false).
Chances are that we do NOT call the ::unload() method everytime we remove a character from the stage. This might be intentional or a bug. In case it is intentional, it's surely done to avoid calling the onUnload method, we might fix by adding an optional parameter to the ::unload() method to specify wheter to call onUnload, if this is optional.
BTW, reguarding this bug, I think I tried with GC disabled and it was still happening...
|
Tue 10 Jul 2007 12:58:41 AM UTC, comment #6:
Question: Can I assume that all characters which are to be deleted by GC are unloaded(character::isUnloaded() return true)?
I found GC removes some characters which have not been unloaded. I am not sure if this should happen. Should we always unload a character(done before starting GC) before we remove it?
|
Fri 06 Jul 2007 07:37:59 AM UTC, comment #5:
OK, confirmed. Current head has a segfault with this. Thanks.
|
Thu 05 Jul 2007 06:20:12 PM UTC, comment #4:
I confirm that's the movie.
md5sum: 5b23b810dfb3bbebdf24881dad228871
Make sure you're using current head, maybe ?
|
Wed 04 Jul 2007 01:22:30 AM UTC, comment #3:
Can you provide a link to the file you used?
This is the file I found from google search:
http://funcop.net/SimGirl.swf
I need to confirm first if this is the file you tried. I haven't found a way to repeat the problem with this file yet.
|
Mon 02 Jul 2007 03:47:53 PM UTC, comment #2:
See also bug #20319
|
Mon 02 Jul 2007 03:09:50 PM UTC, comment #1:
I confirm it's a problem with the NEW_KEY_LISTENER_DESIGN.
Undefining that macro fixes the bug.
|
Mon 02 Jul 2007 02:49:33 PM UTC, original submission:
Playing SimGirl.swf (even with sound disabled) results in a segfault after some user interaction.
Here's the backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1222867264 (LWP 29888)]
0xb65544c0 in ?? ()
(gdb) bt
#0 0xb65544c0 in ?? ()
#1 0xb778d82d in __dynamic_cast (src_ptr=0xb6557358, src_type=0x8727af0, dst_type=0x8728e18, src2dst=0)
at ../../../../src/libstdc++-v3/libsupc++/tinfo.cc:718
#2 0x0819ae79 in gnash::movie_root::cleanup_key_listeners (this=0x0) at /home/strk/src/gnash/gnash-head/server/movie_root.cpp:687
And here's valgrind report:
==8769== Invalid read of size 4
==8769== at 0x48F17C9: __dynamic_cast (tinfo.cc:124)
==8769== by 0x819AE78: gnash::movie_root::cleanup_key_listeners() (movie_root.cpp:687)
==8769== by 0x81A029B: gnash::movie_root::advance(float) (movie_root.cpp:592)
==8769== by 0x83E71E3: gnash::Gui::advance_movie(gnash::Gui*) (gui.cpp:462)
==8769== by 0x463F4A7: (within /usr/lib/libglib-2.0.so.0.1000.3)
==8769== by 0x463D8D5: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.1000.3)
==8769== by 0x4640995: (within /usr/lib/libglib-2.0.so.0.1000.3)
==8769== by 0x4640CB7: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.1000.3)
==8769== by 0x4156764: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.800.20)
==8769== by 0x83E015A: gnash::GtkGui::run() (gtk.cpp:324)
==8769== by 0x83DFC3A: gnash::Player::run(int, char*, char const, char const*) (Player.cpp:366)
==8769== by 0x80F7E50: main (gnash.cpp:398)
==8769== Address 0x6D12ED0 is 0 bytes inside a block of size 284 free'd
==8769== at 0x401D3B6: operator delete(void*) (vg_replace_malloc.c:244)
==8769== by 0x83B6370: gnash::button_character_instance::~button_character_instance() (button_character_instance.cpp:289)
==8769== by 0x83DB56B: gnash::GC::cleanUnreachable() (GC.cpp:89)
It seems related to key listeners
(maybe a key listener did not
unregister self from the movie_root list of listeners, and movie_root is not keeping the characters alive).
It's weird, because the button_character_instance() destructor
is unregistering self from the key listeners...
|