1.4 - better from Jenkins
Locked
123
123
Re: 1.4 - better from Jenkins
 
|
Stef,
I have an idea for something that might be simple enough to make the point. It is confusing though, especially that once an image goes bad, it stays bad, even though (AFAIK, I don't save it after the damage is done). I have work to do there. Bill ________________________________________ From: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]] Sent: Friday, February 10, 2012 3:29 PM To: [hidden email] Subject: Re: [Pharo-project] 1.4 - better from Jenkins On Feb 9, 2012, at 11:39 PM, Schwab,Wilhelm K wrote: > Sven, > > Fair enough, but the game plan is for people to use Metacello configurations to load what they need to build an image. I am attempting to do just that, and am reporting (rather negative so far) experience, with debug logs. Sure we will start to work on distribution certification as I mentioned in the draft of Pharo Vision document which escape my hd recently.. new version coming soon. Bill can you post a reproachable case for us to play with? > > Pharo's fault or not, something is broken. But if Pharo is going to send users into the current state of Metacello, the weather around the lighthouse is going to be grim. > > Interesting ideas about the package cache being damaged. Maybe the logs will reveal something?? > > Bill > > ________________________________________ > From: [hidden email] [[hidden email]] on behalf of Sven Van Caekenberghe [[hidden email]] > Sent: Thursday, February 09, 2012 5:14 PM > To: [hidden email] > Subject: Re: [Pharo-project] 1.4 - better from Jenkins > > On 09 Feb 2012, at 22:27, Schwab,Wilhelm K wrote: > >> My new 1.4 image is behaving a *little* better than its predecessors, but there is still a problem. It seems to happen after invoking Metacello loads, even with the mirror. Odd behaviors include: >> >> (1) can't open debugger >> (2) can't open process browser >> (3) intermittent flashing/alternating cursors in text editors. >> >> Whatever happens, it seems to be saved into the image as MC works, because killing the image and reloading results in a hobbled system. >> >> At least with 1.4, I can sometimes break into a debugger, presumably because something is busy in a tight loop. That might be a/the parser?? >> >> BTW, in an hour (max) of playing around, I've generated a 38 MB debug log - too big to read :( There are mentions of a parser, but my grep creativity has not allowed me to pull out any useful information. Perhaps I can start over with a clean log, let it get into some trouble, and review the log at a smaller size. >> >> Suggestions? > > Some remarks: > > - if you load code and it fails for whatever reason, and there was no hidden save somewhere, I would be extremely surprised if killing the image (clean or otherwise) would result in permanent damage; the only side effect could be in your filesystem (local package cache), but even that would normally not hurt the image itself > > - you are obviously loading lots of stuff: when this does not work, that is not 'Pharo's fault', you should ask the people who wrote these libraries for help (maybe through this list); you can't call gcc crap or unstable when a certain library fails > > - when you are reporting bugs and ask for help, you really have to bring your problem down to a simple test case that others can reproduce; even if people would want to help you, they cannot do so with these generalizations > > Sven > > > |
Re: 1.4 - better from Jenkins
|
|
In reply to this post by Stéphane Ducasse
On Feb 10, 2012, at 9:36 PM, Schwab,Wilhelm K wrote: > Stef, > > I am trying to simplify it :) You use a Mac, right? I'm using Linux, and the vm differences might be at play?? > How can we know if we can not reproduce the problem? Marcus -- Marcus Denker -- http://marcusdenker.de |
Re: 1.4 - better from Jenkins
|
|
In reply to this post by Schwab,Wilhelm K
On Feb 10, 2012, at 9:36 PM, Schwab,Wilhelm K wrote: > Stef, > > I am trying to simplify it :) tx > You use a Mac, right? I'm using Linux, and the vm differences might be at play?? May be. > > Thanks for understanding my motivations. I'll keep at it. It might also be interesting for me to try to orchestrate an attempt on a Windows vm. I don't care for Windows, but I have long respected Andreas' work on it vm. > > Bill > > > ________________________________________ > From: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]] > Sent: Friday, February 10, 2012 3:26 PM > To: [hidden email] > Subject: Re: [Pharo-project] 1.4 - better from Jenkins > > bill > > can you build a reproducable situation? > Because we use daily packages with 1.4 > > In fact in often only develop in 1.4 and did not experience this problem. but it does not mean that we do not have problems :) > > Stef > > > On Feb 9, 2012, at 9:15 PM, Schwab,Wilhelm K wrote: > >> One snag: I'm still getting strangely broken images (won't open process browser or debugger) after trying to download some things. I have mirrored squeak source, BUT, some things (SIXX, ODBC) don't appear to have working configs, so I'm trying to grab the latest packages, and *that* might not be mirrored. I might need to specify the mirror server in my code to make them work. >> >> Still, I don't get how simply asking MC to download something will permanently mar the image w/o my doing an explicit save. Does MC snapshot before/during an attempted load? It seems very misguided that an innocent attempt to load something can hobble an image?? >> >> One other crazy possibility: is killing a vm from the (Ubunutu) system monitor somehow not sufficient to clear what is running? Dumb question? Maybe, but I'm stumped. Any ideas? >> >> Bill >> >> >> >> ________________________________________ >> From: [hidden email] [[hidden email]] on behalf of blake [[hidden email]] >> Sent: Thursday, February 09, 2012 2:58 PM >> To: [hidden email] >> Subject: Re: [Pharo-project] 1.4 - better from Jenkins >> >> I just downloaded the latest CogWin and Pharo 1.4 image and I got >> "WARNING: Manufactured file handle detected!" at the bottom, and popup >> full of startup errors. >> >> But! >> >> It's all actually very friendly! I can look through the errors and try >> to figure out what caused them. It's way cleaner than the old style >> mega-DNU-stacks. >> >> Nice work! >> >> On Thu, Feb 9, 2012 at 11:06 AM, Schwab,Wilhelm K <[hidden email]> wrote: >>> I grabbed 1.4 and cog/unix from jenkins, dumped all the files in one >>> directory, made a shell script to run the image using Cog, and all I can say >>> is "wow." >>> >>> The usability problems I was having are gone. In particular, the context >>> menus work. I loaded Migrate and set preferences, with a really nice >>> appearance resulting. >>> >>> One question: why did ClassDescription>>package go away? That seems to be a >>> really useful message. >>> >>> I'll try to build an image using the SqueakSource mirror. No promises, but >>> 1.4 "suddenly" looks a LOT more polished than it did. Are the links on the >>> Pharo page old, or did somebody just do a lot of work to make things better? >>> >>> Bill >>> >>> >> >> > > > |
Re: 1.4 - better from Jenkins
|
|
In reply to this post by Marcus Denker-4
marcus may be we should integrate the rollback suggested by igor :)
Now I go to bed because a doctor touches my vertebra and I need to lay down :). On Feb 10, 2012, at 9:38 PM, Marcus Denker wrote: > > On Feb 10, 2012, at 9:36 PM, Schwab,Wilhelm K wrote: > >> Stef, >> >> I am trying to simplify it :) You use a Mac, right? I'm using Linux, and the vm differences might be at play?? >> > How can we know if we can not reproduce the problem? > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > |
|
|
In reply to this post by Schwab,Wilhelm K
Schwab,Wilhelm K wrote:
> Stef, > > I have an idea for something that might be simple enough to make the point. It is confusing though, especially that once an image goes bad, it stays bad, even though (AFAIK, I don't save it after the damage is done). For certainty, you could monitor file timestamps or in the extreme compare md5 checksums on the image at various points. Perhaps the first thing after unzippping a new image add 'self halt' at the top of SmalltalkImage>>snapshot:andQuit: This might help hunt down anything that is forcing an image save without your consent. cheers, -ben |
Re: 1.4 - better from Jenkins
|
|
That's if the debugger still works =:0 Good idea though.
________________________________________ From: [hidden email] [[hidden email]] on behalf of Ben Coman [[hidden email]] Sent: Friday, February 10, 2012 8:17 PM To: [hidden email] Subject: Re: [Pharo-project] 1.4 - better from Jenkins Schwab,Wilhelm K wrote: > Stef, > > I have an idea for something that might be simple enough to make the point. It is confusing though, especially that once an image goes bad, it stays bad, even though (AFAIK, I don't save it after the damage is done). For certainty, you could monitor file timestamps or in the extreme compare md5 checksums on the image at various points. Perhaps the first thing after unzippping a new image add 'self halt' at the top of SmalltalkImage>>snapshot:andQuit: This might help hunt down anything that is forcing an image save without your consent. cheers, -ben |
|
|
In reply to this post by Camillo Bruni
Camillo Bruni wrote:
> On 2012-02-10, at 20:06, Ben Coman wrote: > > >> I just realized that clearing up those two ShouldBeImplementeds from DosFileDirectory did not really prove that startup preferences worked on MS Windows. >> So I found the StartupLoader class>>example method >> and did get... 'I should only be displayed once' ...one time only >> and do get... 'I should be displayed each time' ...each time I start Pharo. So its good :) !! >> >> However the 'each time' also dialog comes _every_ time I save the image. Is that desired behaviour? or is it just not finished yet? >> > > see http://code.google.com/p/pharo/issues/detail?id=5275 ;) > |
Re: Debugger hanging... was Re: 1.4 - better from Jenkins
|
|
In reply to this post by Ben Coman
On Feb 10, 2012, at 6:42 PM, Ben Coman wrote: > While I was working towards implementing DosFileDirectory>>preferencesFolder & >>preferencesGeneralFolder > I was stepping through: SmalltalkImage>>snapshot:andQuit: did a: <Restart> > and then stepped down to: Cursor write show > at which point the debugger hung the image. > > Now I guess theres an equal chance this is not really an issue as something "special" might be happening here straddling the save point. Just thought I would report it for review. > > To reproduce on non-Windows you could probably set preferencesFolder & preferencesGeneralFolder on your platform to self shouldBeImplemented and proceed from the debugger that comes up. > > SmalltalkImage>>snapshot: save andQuit: quit > | snapshotResult resuming startupErrors | > Object flushDependents. > Object flushEvents. > self addSnapshotRecord: save andQuit: quit. > self processShutDownList: quit. > Cursor write show. <--------Image Hangs Here after a <Restart> of the method while debugging following a resume.. > > cheers, -ben IIRC, the InputEventSensor is deregistered as part of shutdown, if so, that would indeed lead to a non-responsive image at that point. (In the sense that the thing that processes input is no longer there) Cheers, Henry |
Re: Debugger hanging... was Re: 1.4 - better from Jenkins
|
|
On 13 February 2012 12:55, Henrik Johansen <[hidden email]> wrote:
> > On Feb 10, 2012, at 6:42 PM, Ben Coman wrote: > >> While I was working towards implementing DosFileDirectory>>preferencesFolder & >>preferencesGeneralFolder >> I was stepping through: SmalltalkImage>>snapshot:andQuit: did a: <Restart> >> and then stepped down to: Cursor write show >> at which point the debugger hung the image. >> >> Now I guess theres an equal chance this is not really an issue as something "special" might be happening here straddling the save point. Just thought I would report it for review. >> >> To reproduce on non-Windows you could probably set preferencesFolder & preferencesGeneralFolder on your platform to self shouldBeImplemented and proceed from the debugger that comes up. >> >> SmalltalkImage>>snapshot: save andQuit: quit >> | snapshotResult resuming startupErrors | >> Object flushDependents. >> Object flushEvents. >> self addSnapshotRecord: save andQuit: quit. >> self processShutDownList: quit. >> Cursor write show. <--------Image Hangs Here after a <Restart> of the method while debugging following a resume.. >> >> cheers, -ben > > IIRC, the InputEventSensor is deregistered as part of shutdown, if so, that would indeed lead to a non-responsive image at that point. (In the sense that the thing that processes input is no longer there) > Well, its #shutDown method is empty. But still, i think you have right insight. Because there is enough of Delay>>shutDown to stop everything, because most stuff using delays , including UI process. ---- shutDown "Suspend the active delay, if any, before snapshotting. It will be reactived when the snapshot is resumed." "Details: This prevents a timer interrupt from waking up the active delay in the midst snapshoting, since the active delay will be restarted when resuming the snapshot and we don't want to process the delay twice." > Cheers, > Henry -- Best regards, Igor Stasenko. |
Re: Debugger hanging... was Re: 1.4 - better from Jenkins
|
|
In reply to this post by Henrik Sperre Johansen
Sig,
Has there been any decision/update on this? One good suggestion to get to the bottom of my problem is to set a breakpoint in the snapshot code. But, I currently have little faith that this will reveal an offender, because one of the early symptoms of my images going bad is that debuggers will no longer open. If reverting a change or whatever else fixes this, it could be a big help in finding my problem, if not (via event sensor) a fix to it. Bill ________________________________________ From: [hidden email] [[hidden email]] on behalf of Henrik Johansen [[hidden email]] Sent: Monday, February 13, 2012 6:55 AM To: [hidden email] Subject: Re: [Pharo-project] Debugger hanging... was Re: 1.4 - better from Jenkins On Feb 10, 2012, at 6:42 PM, Ben Coman wrote: > While I was working towards implementing DosFileDirectory>>preferencesFolder & >>preferencesGeneralFolder > I was stepping through: SmalltalkImage>>snapshot:andQuit: did a: <Restart> > and then stepped down to: Cursor write show > at which point the debugger hung the image. > > Now I guess theres an equal chance this is not really an issue as something "special" might be happening here straddling the save point. Just thought I would report it for review. > > To reproduce on non-Windows you could probably set preferencesFolder & preferencesGeneralFolder on your platform to self shouldBeImplemented and proceed from the debugger that comes up. > > SmalltalkImage>>snapshot: save andQuit: quit > | snapshotResult resuming startupErrors | > Object flushDependents. > Object flushEvents. > self addSnapshotRecord: save andQuit: quit. > self processShutDownList: quit. > Cursor write show. <--------Image Hangs Here after a <Restart> of the method while debugging following a resume.. > > cheers, -ben IIRC, the InputEventSensor is deregistered as part of shutdown, if so, that would indeed lead to a non-responsive image at that point. (In the sense that the thing that processes input is no longer there) Cheers, Henry |
Re: Debugger hanging... was Re: 1.4 - better from Jenkins
|
|
In reply to this post by Igor Stasenko
My bad; I meant the InputEventFetcher, the effect is the same.
Cheers, Henry On Feb 13, 2012, at 2:41 PM, Igor Stasenko wrote: > On 13 February 2012 12:55, Henrik Johansen <[hidden email]> wrote: >> >> On Feb 10, 2012, at 6:42 PM, Ben Coman wrote: >> >>> While I was working towards implementing DosFileDirectory>>preferencesFolder & >>preferencesGeneralFolder >>> I was stepping through: SmalltalkImage>>snapshot:andQuit: did a: <Restart> >>> and then stepped down to: Cursor write show >>> at which point the debugger hung the image. >>> >>> Now I guess theres an equal chance this is not really an issue as something "special" might be happening here straddling the save point. Just thought I would report it for review. >>> >>> To reproduce on non-Windows you could probably set preferencesFolder & preferencesGeneralFolder on your platform to self shouldBeImplemented and proceed from the debugger that comes up. >>> >>> SmalltalkImage>>snapshot: save andQuit: quit >>> | snapshotResult resuming startupErrors | >>> Object flushDependents. >>> Object flushEvents. >>> self addSnapshotRecord: save andQuit: quit. >>> self processShutDownList: quit. >>> Cursor write show. <--------Image Hangs Here after a <Restart> of the method while debugging following a resume.. >>> >>> cheers, -ben >> >> IIRC, the InputEventSensor is deregistered as part of shutdown, if so, that would indeed lead to a non-responsive image at that point. (In the sense that the thing that processes input is no longer there) >> > > Well, its #shutDown method is empty. > But still, i think you have right insight. > > Because there is enough of Delay>>shutDown to stop everything, because > most stuff using delays , including UI process. > ---- > shutDown > "Suspend the active delay, if any, before snapshotting. It will be > reactived when the snapshot is resumed." > "Details: This prevents a timer interrupt from waking up the active > delay in the midst snapshoting, since the active delay will be > restarted when resuming the snapshot and we don't want to process the > delay twice." > > >> Cheers, >> Henry > > > > -- > Best regards, > Igor Stasenko. > |
|
|
In reply to this post by Schwab,Wilhelm K
The error I reported here should not affect your using a breakpoint
#snapshot:andQuit in to debug this. Just avoid clicking <restart> in the debugger for #snapshot:andQuit: For your problem with the debugger, here is how I would go about it. 1. Check if any failures occur with TestRunner on ToolsTest-Debugger? If any of them do fail (for example #testBasic), then use that as an observation point to help isolate the problem. 2. Automate the loading of additional code using the new preferences feature. After each step check whether #testBasic now fails. This hopefully makes it reproducible and facilitates divide and conquer to isolate which code is interfering with the debugger. A possible startup script (pseudocode) Transcript open. Transcript crShow: 'Loading A failures = ' Load the code for A Transcript show: ( DebuggerTest run: #testBasic ) failures size Transcript crShow: 'Loading B failures = ' Load the code for B Transcript show: ( DebuggerTest run: #testBasic ) failures size ...etc Execute `StartupLoader example` to generate a template startup script. Unzip a fresh image. Seed the local package cache from a previous image. Run the image. 3. Set Debugger>>logDebuggerStackToFile and see if anything spits out (note I haven't used this myself - just saw it in the code) cheers, -ben Schwab,Wilhelm K wrote: > Sig, > > Has there been any decision/update on this? One good suggestion to get to the bottom of my problem is to set a breakpoint in the snapshot code. But, I currently have little faith that this will reveal an offender, because one of the early symptoms of my images going bad is that debuggers will no longer open. > > If reverting a change or whatever else fixes this, it could be a big help in finding my problem, if not (via event sensor) a fix to it. > > Bill > > > ________________________________________ > From: [hidden email] [[hidden email]] on behalf of Henrik Johansen [[hidden email]] > Sent: Monday, February 13, 2012 6:55 AM > To: [hidden email] > Subject: Re: [Pharo-project] Debugger hanging... was Re: 1.4 - better from Jenkins > > On Feb 10, 2012, at 6:42 PM, Ben Coman wrote: > > >> While I was working towards implementing DosFileDirectory>>preferencesFolder & >>preferencesGeneralFolder >> I was stepping through: SmalltalkImage>>snapshot:andQuit: did a: <Restart> >> and then stepped down to: Cursor write show >> at which point the debugger hung the image. >> >> Now I guess theres an equal chance this is not really an issue as something "special" might be happening here straddling the save point. Just thought I would report it for review. >> >> To reproduce on non-Windows you could probably set preferencesFolder & preferencesGeneralFolder on your platform to self shouldBeImplemented and proceed from the debugger that comes up. >> >> SmalltalkImage>>snapshot: save andQuit: quit >> | snapshotResult resuming startupErrors | >> Object flushDependents. >> Object flushEvents. >> self addSnapshotRecord: save andQuit: quit. >> self processShutDownList: quit. >> Cursor write show. <--------Image Hangs Here after a <Restart> of the method while debugging following a resume.. >> >> cheers, -ben >> > > IIRC, the InputEventSensor is deregistered as part of shutdown, if so, that would indeed lead to a non-responsive image at that point. (In the sense that the thing that processes input is no longer there) > > Cheers, > Henry > > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |