Hi Ben, Sorry, I do not have yet a verdict. The part of the system that reproduces the crash is not used frequently so it takes me quite some time to reproduce it :( Will keep you informed if I see it again or not with the last changes.
Thanks for checking with me. On Mon, Aug 8, 2016 at 12:43 PM, Ben Coman <b...@openinworld.com> wrote: > Hi Mariano, How are you going with this problem? > > On Fri, Jul 22, 2016 at 11:05 PM, Mariano Martinez Peck > <marianop...@gmail.com> wrote: > > > > > > On Fri, Jul 22, 2016 at 2:26 AM, Ben Coman <b...@openinworld.com> wrote: > >> > >> > >> > >> On Fri, Jul 22, 2016 at 4:42 AM, Mariano Martinez Peck > >> <marianop...@gmail.com> wrote: > >>> > >>> > >>> > >>> On Sun, Jul 17, 2016 at 6:46 AM, Ben Coman <b...@openinworld.com> > wrote: > >>> > >>>> > >>>> Do you have some test code or a test image I could run to reproduce > >>>> the problem? > >>> > >>> > >>> > >>> The problem is that I cannot reproduce it immediately. It takes me some > >>> days and likely some image save and start again until I reproduce it. > >> > >> > >> Could you try > >> How about something that invokes > >> > > > > > > Hi Ben. I tried to reproduce it in a couple of ways, trying to simulate > what > > I do for real but I failed: > > > > | commandString | > > commandString := 'wkhtmltopdf --javascript-delay 300 --encoding utf8 > > --page-size A4 --image-quality 100 --footer-spacing 10 > --header-spacing 10 > > --margin-top 10 --header-html "http://google.com"; --footer-html > > "http://google.com"; "http://pharo.org/"; "/tmp/TestPharoExport.pdf"'. > > > > 10 timesRepeat: [ > > > > 3 timesRepeat: [ > > OSSUnixSubprocess new > > shellCommand: commandString; > > redirectStdout; > > redirectStderr; > > runAndWaitOnExitDo: [ :command :outString :errString | > > Transcript show: errString. > > Transcript show: outString. > > ]. > > ]. > > Smalltalk saveSession. > > > > ] > > > > But...I could not yet reproduce it in the real case either....so I will > keep > > you informed. > > > > > >>> > >>> > >>>> > >>>> > >>>> Now I have one thing for you to try. In the move of DelaySchedulerXxx > >>>> from milliseconds to microseconds, the code for dealing with clock > >>>> wrap-around was removed, but I wonder if it was also covering clock > >>>> jitter as a side effect. Could you try again the SpinScheduler but > >>>> restore this code... > >>>> > >>>> From handletTimerEvent... > >>>> "Check for clock wrap-around." > >>>> millisecondNowTick < activeDelayStartTime ifTrue: [ > >>>> "clock wrapped" > >>>> self saveResumptionTimes. > >>>> self restoreResumptionTimes ]. > >>>> activeDelayStartTime := millisecondNowTick. > >>>> > >>>> From runTimerEventLoop... > >>>> Time millisecondClockValue < millisecondNowTick > >>>> ifTrue:[ timingSemaphore signal ]. "retry" > >>>> > >>>> From startup... > >>>> activeDelayStartTime := Time millisecondClockValue. > >>>> > >>> > >>> OK, I put back the code into the spin scheduler. Then I kept using > >>> milisecond one until I finished the changes. Then I saved image and > switch > >>> to spin one: the image hungs. I cannot even interrupt it. I attach my > >>> modifications. > >>> Do they look correct? > >> > >> > >> I confirm that locked my image also. > >> > >> One change of milli to micro was missed at the bottom of > >> runTimeEventLoop... > >> That is... > >> Time millisecondClockValue < microsecondNowTick > >> to... > >> Time microsecondClockValue < microsecondNowTick > >> > > Thanks. That did the trick! > > -- Mariano http://marianopeck.wordpress.com
