Skip Menu |

This queue is for tickets about the Fuse CPAN distribution.

Report information
The Basics
Id: 34284
Status: resolved
Priority: 0/
Queue: Fuse

People
Owner: DPAVLIN [...] cpan.org
Requestors: verymuch.happyman [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 0.11



Subject: Fall at reading in multithreaded mode
Date: Thu, 20 Mar 2008 21:54:09 +0700
To: bug-Fuse [...] rt.cpan.org
From: verymuch.happyman [...] gmail.com
Env: - Fuse-0.09 - $ perl -v This is perl, v5.8.8 built for i386-linux-thread-multi - Operating System: Fedora 8 - fuse 2.7.0 Bug: - Then call "read" with different files at the same time and very often in multithreaded mode Fuse.pm it`s die: Use of uninitialized value in null operation at /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/Fuse.pm line 121. Undefined subroutine &main:: called at /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/Fuse.pm line 121. - Problem exists in LftpFS ( http://lftpfs.sf.net ) which based on Fuse.pm and when it read diffrenet files simultaneously in multithreaded mode.
I am experiencing the exact same error, also with perl 5.8.8 at the same line in Fuse.pm, but with a project that doesn't involve lftpfs at all. Show quoted text
> Use of uninitialized value in null operation at > /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/Fuse.pm line 121. > Undefined subroutine &main:: called at > /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/Fuse.pm line 121.
I suspect this is a bug with perl threading support. As in the original problem description, I only encounter this under high throughput with threading enabled.
I never managed to reproduce this problem. Do you still see this problem?
From: daniel.frett [...] ccci.org
On Mon May 17 12:48:17 2010, DPAVLIN wrote: Show quoted text
> I never managed to reproduce this problem. Do you still see this problem?
I just ran into this error on the latest code from github, doing a bit of debugging I found that the refcount of SVs in the _PLfuse_callbacks array get messed up under high threaded load. I was able to pretty reliably reproduce this by using the loopback_t.pl example on a directory with a lot of files and subdirectories, then running the following command on multiple terminals: "while true; do ls -alR fuseTest; done". The problem seems to go away by removing the call to SvSHARE on the SVs being stored in the array. This call shouldn't be necessary because the callback SVs will be automatically cloned to other threads when perl_clone is called, and are never updated after fuse_loop_mt is started. This would seem to indicate that this may be a threads::shared refcount race condition and be triggered again by passing in an already shared variable for a callback. I don't have enough perl threads knowledge/experience or time right now to be able to track this down any further to find and fix any potential underlying issues. I pushed a patch up to github here: https://github.com/frett/perl-fuse/tree/RT34284
From: daniel.frett [...] ccci.org
On Tue Feb 08 13:30:47 2011, dfrett wrote: Show quoted text
> On Mon May 17 12:48:17 2010, DPAVLIN wrote:
> > I never managed to reproduce this problem. Do you still see this
> problem? > > I just ran into this error on the latest code from github, doing a bit > of debugging I found that > the refcount of SVs in the _PLfuse_callbacks array get messed up under > high threaded load. > > I was able to pretty reliably reproduce this by using the > loopback_t.pl example on a directory > with a lot of files and subdirectories, then running the following > command on multiple > terminals: "while true; do ls -alR fuseTest; done". > > The problem seems to go away by removing the call to SvSHARE on the > SVs being stored in > the array. This call shouldn't be necessary because the callback SVs > will be automatically > cloned to other threads when perl_clone is called, and are never > updated after fuse_loop_mt is > started. > > This would seem to indicate that this may be a threads::shared > refcount race condition and > be triggered again by passing in an already shared variable for a > callback. I don't have > enough perl threads knowledge/experience or time right now to be able > to track this down > any further to find and fix any potential underlying issues. > > I pushed a patch up to github here: https://github.com/frett/perl- > fuse/tree/RT34284 >
I tracked down the actual cause of this bug to the fact that the callbacks were not being stored in a thread safe manner and all threads were accessing the SV's referencing the callbacks from the master thread. This led to race conditions with ref counting when the SV had the SvSHARE magic on it were passed to call_sv. I fixed the issue by implementing thread-safe static data storage utilizing the MY_CXT mechanism documented here: http://search.cpan.org/~rjbs/perl- 5.12.3/pod/perlxs.pod#Safely_Storing_Static_Data_in_XS I have tested this on perl5.10.1 and have not been able to reproduce the race condition. Another potential side-effect of this fix is the support for closures as callbacks due to the callback SV's being cloned to new threads the same way all other perl data is cloned. I have not tested this functionality yet to know if this does definitely work now or not. I made created a pull request on github with my patch here: https://github.com/dpavlin/perl-fuse/pull/2 -Daniel
RT-Send-CC: daniel.frett [...] ccci.org
Daniel, thanks a lot for tracking this bug down. I merged your changes in github repo and plan to release new 0.11 version later this week to CPAN.