bugGnash - The GNU Flash player - Bugs: bug #24194, trunk: too early CurlSession...

 
 

bug #24194: trunk: too early CurlSession destruction

Submitted by:  -Deleted Account- <geki>
Submitted on:  Wed 03 Sep 2008 01:35:45 PM UTC  
 
Category: NoneSeverity: 5 - Blocker
Release: NoneStatus: Fixed
Privacy: PublicAssigned to: Sandro Santilli <strk>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Thu 04 Sep 2008 10:13:11 AM UTC, comment #9:

Yes, commit bzr9674 fixed my bug, thank you! :)

-Deleted Account- <geki>
Thu 04 Sep 2008 09:52:34 AM UTC, comment #8:

Yes, as I said I've seen the shared handle error in other circumstances, but only rarely. I'm sure it is fixed, but it is better for someone who could reproduce the error reliably to confirm.

Benjamin Wolsey <bwy>
Project Member
Thu 04 Sep 2008 09:39:07 AM UTC, comment #7:

I never reproduced the segfault, but was pretty easy
to get the ERROR about failure to cleanup share handle,
ever noticed ?
It requires passing a network url on command line, with -v...
With trunk, you shoulnd't get that message anymore.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Thu 04 Sep 2008 07:32:07 AM UTC, comment #6:

I like the new callback mechanism. Can we use it for yesno too? It would be great if libcore didn't access Gui again.

I couldn't reproduce the problem here (although I have seen it occasionally elsewhere), so I can't confirm any fix. Didn't try it with the loop patch either.

Benjamin Wolsey <bwy>
Project Member
Thu 04 Sep 2008 03:11:45 AM UTC, comment #5:

I committed a patch reworking core<->host communication
and allowing for stateful callbacks.
This way Players' _gui can be non-static again and
this bug is fixed for me.
Tests welcome (both for this bug AND for core<->host comm).

NOTE: if curl deinitialization will fail again now, gnash
would hung on exit (will eventually cleanup after more
testing).

Sandro Santilli <strk>
Project MemberIn charge of this item.
Thu 04 Sep 2008 01:24:57 AM UTC, comment #4:

Benjamin, it turns out your revision number 8002 changed Player's _gui member to a static one, thus introducing this problem, that is
unpredictable deinitialization order (the static Gui happens to be deleted after the static CurlSession).

The switch to a static Gui seems to be related to the interfaceEventCallback thing.
I'll try to fix myself, but wanted to let you know..

Sandro Santilli <strk>
Project MemberIn charge of this item.
Thu 04 Sep 2008 12:40:37 AM UTC, comment #3:

So, what happens is:

1) top-level movie is created and passed the IOChannel (curl) for input
2) IOChannel is owned by the movie and will be deleted by it
3) The function-static CurlSession gets deleted BEFORE the top-level movie (SWFMovieDefinition).

Now, this is one of those cases where we don't control
deinitialization order (a static, and a leaking SWFMovie?).

The bug was likely introduced by fixing the premature deletion
of SWFMovieDefinition with limited MovieLibrary (bug #23364).
See this comment in Player.cpp:

// NOTE: the loader thread might (in IMPORT tag parsing)
// create new movies and register them to the MovieLibrary.
// If MovieLibrary size exceeded, _movieDef might be
// destroyed prematurely. movie_root might actually be
// keeping it alive, as Gui might as well, but why relying
// on luck ? So we made sure to keep _movieDef by
// intrusive_ptr...

Sandro Santilli <strk>
Project MemberIn charge of this item.
Wed 03 Sep 2008 02:35:04 PM UTC, comment #2:

Uhm... the url you report and the code I suggested keeps
trying w/out success:

23117:3056158496] 16:33:19 ERROR: Failed cleaning up share handle: share currently in use. Will try again in a second.
...
23117:3056158496] 16:34:15 ERROR: Failed cleaning up share handle: share currently in use. Will try again in a second.
...

I wonder what keeps the handle busy.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Wed 03 Sep 2008 02:29:19 PM UTC, comment #1:

I often see the :

Failed cleaning up share handle: handle still in use

kind of message too.

We have 2 options:

1) try in a loop, sleeping between calls
2) don't global_cleanup if share cleanup fails

Option 2 won't properly flush cookies.
Option 1 should catch threading bugs (unclean shutdown).

I'll try option 1 first.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Wed 03 Sep 2008 01:35:45 PM UTC, original submission:

./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-visibility --disable-cygnal --disable-ghelp --disable-kparts --enable-nsapi --disable-i810-lod-bias --disable-mit-shm --enable-gui=gtk --without-included-ltdl --with-ltdl-include=/usr/include --with-ltdl-lib=/usr/lib64 --with-npapi-plugindir=/opt/netscape/plugins --enable-renderer=ogl --enable-media=gst --libdir=/usr/lib64 --build=x86_64-pc-linux-gnu

My problem:
Sometimes gnash leads firefox to segfault on page change.
Executing these .swf files with gtk-gnash I get a SIGABRT on exit.

Checking with gdb tells me that the CurlSession object is destroyed before a CurlStreamFile object. Now that the CurlSession object initilizes and destroys libcurl access with curl_global_init and curl_global_cleanup the SIGABRT is to be expected, I guess.

How to reproduce:
$ gdb /usr/bin/gtk-gnash
(gdb) set args http://content.yieldmanager.edgesuite.net/atoms/2b/91/2b91dd731702bbac41f5304886acba64.swf
(gdb) break lockSharedHandle
(gdb) break unlockSharedHandle
(gdb) run
(gdb) c

# repeat 11 times in total

Breakpoint 3, gnash::curl_adapter::CurlSession::lockSharedHandle (this=0x7f16c0509520, handle=0x0, data=CURL_LOCK_DATA_SHARE, access=CURL_LOCK_ACCESS_SINGLE) at curl_adapter.cpp:273
273 in curl_adapter.cpp
(gdb)
Continuing.

Breakpoint 4, gnash::curl_adapter::CurlSession::unlockSharedHandle (this=0x7f16c0509520, handle=0x0, data=CURL_LOCK_DATA_SHARE) at curl_adapter.cpp:311
311 in curl_adapter.cpp
(gdb) bt
#0 gnash::curl_adapter::CurlSession::unlockSharedHandle (this=0x7f16c0509520, handle=0x0, data=CURL_LOCK_DATA_SHARE) at curl_adapter.cpp:311
#1 0x00007f16bc18085b in curl_share_cleanup () from /usr/lib/libcurl.so.4
#2 0x00007f16c02daaf7 in ~CurlSession (this=0x7f16c0509520) at curl_adapter.cpp:194
#3 0x00007f16bde6718d in exit () from /lib/libc.so.6
#4 0x00007f16bde4f48d in __libc_start_main () from /lib/libc.so.6
#5 0x0000000000413e59 in _start ()
(gdb) c
Continuing.

Breakpoint 3, gnash::curl_adapter::CurlSession::lockSharedHandle (this=0x7f16c0509520, handle=0x1270460, data=CURL_LOCK_DATA_COOKIE, access=CURL_LOCK_ACCESS_SINGLE)
at curl_adapter.cpp:273
273 in curl_adapter.cpp
(gdb) bt
#0 gnash::curl_adapter::CurlSession::lockSharedHandle (this=0x7f16c0509520, handle=0x1270460, data=CURL_LOCK_DATA_COOKIE, access=CURL_LOCK_ACCESS_SINGLE) at curl_adapter.cpp:273
#1 0x00007f16bc18079f in Curl_share_lock () from /usr/lib/libcurl.so.4
#2 0x00007f16bc16df5a in ?? () from /usr/lib/libcurl.so.4
#3 0x00007f16bc170f94 in Curl_close () from /usr/lib/libcurl.so.4
#4 0x00007f16c02da38d in ~CurlStreamFile (this=0x1258950) at curl_adapter.cpp:892
#5 0x00007f16c02e3977 in ~InflaterIOChannel (this=0x1289070) at /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include/g++-v4/backward/auto_ptr.h:173
#6 0x00007f16c07590a0 in ~SWFMovieDefinition (this=0x1288c50) at /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include/g++-v4/backward/auto_ptr.h:173
#7 0x000000000041fad6 in ~Gui (this=0xf96fe0) at ../libbase/ref_counted.h:87
#8 0x000000000042ff42 in ~GtkGui (this=0xf96fe0) at gtk.cpp:93
#9 0x00007f16bde6718d in exit () from /lib/libc.so.6
#10 0x00007f16bde4f48d in __libc_start_main () from /lib/libc.so.6
#11 0x0000000000413e59 in _start ()
(gdb) c
Continuing.

Program received signal SIGABRT, Aborted.

-Deleted Account- <geki>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by bwy (Posted a comment)
  • -unavailable- added by strk
  • -unavailable- added by strk (Posted a comment)
  • -unavailable- added by geki (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 04 Sep 2008 10:16:21 AM UTCstrkStatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Thu 04 Sep 2008 03:11:45 AM UTCstrkStatusIn Progress=>Ready For Test
    Thu 04 Sep 2008 01:24:57 AM UTCstrkCarbon-Copy-=>Added bwy
    Wed 03 Sep 2008 02:29:19 PM UTCstrkSeverity3 - Normal=>5 - Blocker
      StatusNone=>In Progress
      Assigned toNone=>strk

    Back to the top


    Powered by Savane 3.1-cleanup1