Wed 08 Jul 2009 08:33:57 AM UTC, comment #18:
Works generally okay, no segfault. Please file new bug reports for specific problems.
|
Tue 18 Mar 2008 11:28:45 AM UTC, comment #17:
I committed a compromise patch introducing the concept
of "holes" in arrays. It fixes the action limit hit
in that it won't enumerate holes...
|
Tue 18 Mar 2008 07:41:22 AM UTC, comment #16:
Here's a testcase reproducing the problem triggered
by sign-tv new haupt.swf getting to action limit hit:
a = [];
a.length = 1048576;
for (var v in a) { };
The reference player doesn't enumerate all the fake
values, so doesn't hit a limit with the above code.
In the haupt.swf case, the code is really like this:
a = new Array();
a[1048576] = something;
for (var v in a) { };
The array index doesn't seem to result from another bug,
in that it's explicitly pushed on stack, representing
a "reserved" depth for a movieclip (might be a default
for the DepthManager mx component).
So, it looks like the way to fix this bug would be by
fixing enumeration of arrays to only return really existing
elements, w/out inbetweens.
|
Mon 17 Mar 2008 04:05:03 PM UTC, comment #15:
It takes two clicks on the right-arrow for this:
terminate called after throwing an instance of 'gnash::ActionLimitException'
what(): Loop iterations count exceeded limit of 65536. Last branch was from pc 6353 to 6164.
Aborted (core dumped)
|
Mon 17 Mar 2008 04:04:10 PM UTC, comment #14:
It seems I got another segfault with some interaction.
Looks like haupt.swf have changed.
I had 8b69fc600cf8bd3c7d6aae892dfe55ab locally.
The one online is 4aae9d47eefd9bef38af17b4b6225c3d.
|
Fri 14 Mar 2008 11:26:58 AM UTC, comment #13:
I committed a patch that ensures movie_root::cleanupDisplayList
leaves NO unloaded characters in the container.
Fixes the segfault.
And yes, the movie actually works.
|
Fri 14 Mar 2008 09:59:28 AM UTC, comment #12:
Alright, found the problem being in the way movie_root cleans
the _liveInstances container.
Theoretically, unloaded instances will be removed, but
when an unloaded-but-not-destroyed instance is found,
it's ::destroy() method is called.
Now, what happens is that the ::destroy() method unloads
more characters, some of which may have been already scanned
by the _liveInstance scan loop, which then survive the cleanup
scan even if being unloaded.
Scanning again if any ::destroy() was called fixes the problem.
Some stats for this specific movie show that a double scan is
only required once (2 scans at most) and that usually no additional
characters are found unloaded on second scan, except in the case
that triggers our segmentation fault:
Scan 1 cleaned 86 instances
Scan 2 cleaned 48 instances
The above means that one or more unloaded-but-not-destroyed characters did unload (ad destroy) a total of 48 additional
characters when destroy() was called on them.
|
Fri 14 Mar 2008 09:00:52 AM UTC, comment #11:
The segfault is fixed if movie_root::markReachableResources
marks the _liveInstances. Notes there suggest that theoretically
marking shouldn't be there.
|
Fri 14 Mar 2008 08:56:55 AM UTC, comment #10:
When the segfault isn't there, the video plays now.
|
Fri 14 Mar 2008 08:34:43 AM UTC, comment #9:
The segfault is back in head, it seems:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1229567792 (LWP 32713)]
0xb7c015b2 in gnash::movie_root::cleanupDisplayList (this=0x838e3d8) at /home/strk/src/gnash/gnash-head/server/movie_root.cpp:1642
1642 if ( ! ch->isDestroyed() ) ch->destroy();
(gdb) bt
#0 0xb7c015b2 in gnash::movie_root::cleanupDisplayList (this=0x838e3d8) at /home/strk/src/gnash/gnash-head/server/movie_root.cpp:1642
#1 0xb7c0310d in gnash::movie_root::advance (this=0x838e3d8) at /home/strk/src/gnash/gnash-head/server/movie_root.cpp:1041
#2 0x08087227 in gnash::Gui::advanceMovie (this=0x8205238) at /home/strk/src/gnash/gnash-head/gui/gui.cpp:755
#3 0x0809e8a1 in gnash::Gui::advance_movie (gui=0x8205238) at /home/strk/src/gnash/gnash-head/gui/gui.h:212
|
Tue 15 Jan 2008 11:00:44 AM UTC, comment #8:
Confirm the segfault is fixed (although the SWF is slightly different from what it used to be, it looks like the same bug).
If the stream is supposed to be in 'live', which sounds likely, it indeed doesn't work.
|
Tue 15 Jan 2008 10:27:34 AM UTC, comment #7:
The segfault is ready for test.
If confirmed to be fixed we should make this back
to a normal priority bug, confirming the original would
also be nice.
|
Tue 15 Jan 2008 10:01:58 AM UTC, comment #6:
I could reproduce.
The movie is:
http://www.focus-5.tv/live.swf
terminate called after throwing an instance of 'gnash::GnashException'
what(): invalid multi handle
Aborted (core dumped)
|
Sun 30 Dec 2007 09:28:06 AM UTC, comment #5:
InsecureSSL, that would be.
|
Sun 30 Dec 2007 09:27:07 AM UTC, comment #4:
If no one else can reproduce it, feel free to downgrade the bug again. I run with 'set insecureSSH on', which might change CURL behaviour, but otherwise I can't see anything significant. I don't have time to do much testing for a few days, but will look again when I do.
|
Fri 28 Dec 2007 11:59:15 AM UTC, comment #3:
I can't reproduce it, do you have any environment variable which would change CURL behaviour ? The Curl_debug in particular
seems suspicious..
Also, does valgrind report errors ?
|
Thu 27 Dec 2007 06:49:46 PM UTC, comment #2:
http://www.focus-5.tv/haupt.swf is the movie.
|
Thu 27 Dec 2007 06:34:24 PM UTC, comment #1:
This segfaults if you click on any of the people, then on 'Live'. Backtrace:
#1 0x00002b4a484d91a8 in __cxa_pure_virtual () from /usr/lib64/libcurl.so.4
#2 0x00002b4a484d93c2 in Curl_debug () from /usr/lib64/libcurl.so.4
#3 0x00002b4a484d8709 in Curl_infof () from /usr/lib64/libcurl.so.4
#4 0x00002b4a485031c6 in Curl_getaddrinfo () from /usr/lib64/libcurl.so.4
#5 0x00002b4a484cd809 in Curl_resolv () from /usr/lib64/libcurl.so.4
#6 0x00002b4a484e95ea in __cxa_pure_virtual () from /usr/lib64/libcurl.so.4
#7 0x00002b4a484e9ae5 in Curl_connect () from /usr/lib64/libcurl.so.4
#8 0x00002b4a484fcc93 in __cxa_pure_virtual () from /usr/lib64/libcurl.so.4
#9 0x00002b4a484fda23 in curl_multi_perform () from /usr/lib64/libcurl.so.4
#10 0x00002b4a45cc2eb1 in curl_adapter::CurlStreamFile::fill_cache (this=0x1602010, size=1024) at curl_adapter.cpp:346
#11 0x00002b4a45cc32a5 in curl_adapter::CurlStreamFile::read (this=0x1602010, dst=0x161cc00, bytes=1024) at curl_adapter.cpp:610
#12 0x00002b4a45cc32f5 in read (dst=0x1900000000, bytes=1107304432, appdata=0x16091a0) at curl_adapter.cpp:747
#13 0x00002b4a458feaa8 in gnash::LoadVariablesThread::completeLoad (this=0x12debf0) at ../libbase/tu_file.h:186
#14 0x00002b4a48924d5f in boost::function0<void, std::allocator<boost::function_base> >::operator() () from /usr/lib64/libboost_thread.so.1
#15 0x00002b4a48924a0f in __cxa_pure_virtual () from /usr/lib64/libboost_thread.so.1
#16 0x00002b4a45ef82f0 in start_thread () from /lib64/libpthread.so.0
#17 0x00002b4a47e11f9d in clone () from /lib64/libc.so.6
|
Thu 29 Nov 2007 09:49:01 PM UTC, original submission:
dear gnash devs,
i started learning sign language and the best tv-sender in sign language is unfortunately using flash for their stream.
the website:
http://www.focus-5.tv
it states that it needs flash 8 but i hope since it is only a stream and nothing flash-fancy-magic like, that gnash could be made to support it. can you have a look at it, please?
any help appreciated, i'm willing to test patches, however i cannot code myself.
best regards,
Damir
|