[Unison-hackers] mutex

[Benjamin Pierce]

This is more guessing than wisdom, but have you looked at when GC is  
happening?

    - B


On Apr 23, 2006, at 8:15 PM, Ben Willmore wrote:

> Well, I'm stumped.  Here's the problem in detail:
>
> If thread A is running unisonSynchronize (uimacbridge.ml), and thread
> B calls unisonRiToDetails (also uimacbridge.ml), a crash will
> sometimes occur.  [Removing references to the stateItem in
> unisonRiToDetails fixes it.]  My assumption was that both threads were
> trying to access the same stateItem simultaneously.  Either this is
> not the case, or I don't understand unisonSynchronize as well as I
> think I do.
>
> Attached is a patch that demonstrates it. It adds mutex locking in
> unisonRiToDetails and unisonSynchronize, and some NSLog (print)
> statements.
>
> Steps to reproduce the bug:
> Start the Mac GUI from the command line
> Choose two roots with a large number of different small files (I use
> the script below to make 500)
> Scroll down and select the last reconItem, using the scroll bar, *not*
> the down arrow (which would fetch all the details in advance).
> Hit Go
> Hold down the up arrow
>
> You will see:
> Usually, Unison will crash with a bus error (sometimes a segfault,
> occasionally something else).
> The mutexes have no effect in preventing this (though tests show they
> are locking correctly).
> The print statements show something like:
>
> ...
> 2006-04-23 11:46:44.836 Unison[8722] dS: SyncEnd: file34
> 2006-04-23 11:46:44.837 Unison[8722] dS: SyncStart: file340
> 2006-04-23 11:46:44.837 Unison[8722] dS: TransStart: file340
> 2006-04-23 11:46:44.838 Unison[8722] dS: TransStart:  
> file340           file340
> 2006-04-23 11:46:44.841 Unison[8722] dS: SyncEnd: file340
> 2006-04-23 11:46:44.842 Unison[8722] dS: SyncStart: file341
> 2006-04-23 11:46:44.843 Unison[8722] dS: TransStart: file341
> 2006-04-23 11:46:44.843 Unison[8722] dS: TransStart:  
> file341           file341
> 2006-04-23 11:46:44.861 Unison[8722] dS: Details: file9
> 2006-04-23 11:46:44.908 Unison[8722] dS: Details: file89
> 2006-04-23 11:46:45.011 Unison[8722] dS: Details: file88
> 2006-04-23 11:46:45.057 Unison[8722] dS: Details: file87
> 2006-04-23 11:46:45.066 Unison[8722] dS: Details: file86
> 2006-04-23 11:46:45.113 Unison[8722] dS: Details: file85
> 2006-04-23 11:46:45.160 Unison[8722] dS: Details: file84
> 2006-04-23 11:46:45.209 Unison[8722] dS: Details: file83
> 2006-04-23 11:46:45.262 Unison[8722] dS: Details: file82
> 2006-04-23 11:46:45.297 Unison[8722] dS: Details: file81
> 2006-04-23 11:46:45.327 Unison[8722] dS: Details: file80
> 2006-04-23 11:46:45.362 Unison[8722] dS: Details: file8
> 2006-04-23 11:46:45.396 Unison[8722] dS: Details: file79
> Bus error
>
> The files are alphanumerically sorted, so this indicates that files
> file1->file340 have been synced successfully, and we're in the middle
> of syncing file341.  Details have been displayed for files
> file99->file79.  I.E. We haven't got close to a conflict where both
> the sync thread and the GUI thread access the same item.
>
> This is really annoying me.  As far as I can tell, both threads are
> locked everywhere (relevant) that the stateItems are referenced, and
> the log seems to agree this is not the problem.  But I can't see any
> reason why running unisonRiToDetails on file79 should cause a crash
> during synchronization of file341.
>
> Any injection of wisdom would be much appreciated.
>
> Ben
>
>
> ------------
> #!/bin/bash
> # make n=$1 files containing $2
> LIMIT=$1
> for ((a=1; a <= LIMIT ; a++))
> do
>   echo $2 > file$a
> done
> <debug.patch>
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers