Hi everyone, I am currently working on getting the Squeak Jenkins server to perform benchmarking and so far everything is going great except for one thing. When I try to filein code implementing some benchmarks into a headless VM, it just hangs. If I filein the same file to a non-headless VM everything works just fine. Seeing as how things only blow up when I am running headless, debugging is made somewhat more complicated. I was wondering if anyone had some advice on getting better debug information from a headless VM, besides explicit log statements? I was also wondering if this sort of problem is ringing any bells for anyone on the list. I don't really have a good grip on how filein works either, so any pointers would be greatly appreciated. Would filein be attempting to send ui messages that are failing? I didn't see any user input requests when I filed into a normal VM, so I don't think it is waiting on a response. Any help is appreciated. Thanks for your time, |
Hi Jeff,
if you still count this as headless (I do) load RFB into that image and use TightVNC or similar for the UI. I do this on my text only Linux machine. Cheers Herbert
|
As a follow up question for people who have experience working with headless images, would I need to set the "user name" in the image before I file in code? I know that when I make a change in a fresh image that isn't headless it asks me for my initials, is it possible that the filein code is waiting on user input for the initials? On Thu, Feb 7, 2013 at 10:30 AM, Herbert König <[hidden email]> wrote:
|
In reply to this post by Jeff Gonis-2
If you can't see what's going on inside the
headless image, getting some sort of picture would be a
start. Try doing this in the image and save it:
[ [ f _ FileDirectory default fileNamed: 'allMyProcesses'. f nextPutAll: Time now asString; cr. Process allInstances do: [ :p | p suspendedContext ifNotNilDo: [ :ctxt | f nextPutAll: 'priority: ',p priority asString; cr; nextPutAll: ctxt longStack; cr; cr] ]. f close. (Delay forSeconds: 30) wait ] repeat ] forkAt: 60 the output might point you to where things stand. On 2/7/13 12:14 PM, Jeff Gonis wrote:
|
That is awesome. Getting visibility into the image is exactly what I have been grappling with, so this is a big help. On Thu, Feb 7, 2013 at 12:05 PM, Bob Arning <[hidden email]> wrote:
|
On Thu, Feb 7, 2013 at 11:18 AM, Jeff Gonis <[hidden email]> wrote:
and with the Cog VMs on Mac and Linux sending SIGUSR1 to the VM will get it to print out the same to the console (provided you start the VM from a console).
best, Eliot
|
In reply to this post by Jeff Gonis-2
I ran into the initials issue building Seaside 3.1 on travisci.org. If the code you're loading would pop up the initials dialog in headful Squeak then you need to set the initials in the *.st file you use to load the offending code into the image before that code is loaded. On Squeak you can set the initials thusly: Utilities setAuthorInitials: 'pad' And on Pharo Author fullName: 'PaulDeBruicker' and if you want to be able to do it on both platforms from one script: "Set the author in case its needed" ('Pharo*' match: Smalltalk version) ifTrue:[Author fullName: 'PaulDeBruicker']. ('Squeak*' match: Smalltalk version) ifTrue:[Utilities setAuthorInitials: 'pad']. HTH Paul |
In reply to this post by Jeff Gonis-2
On 7 February 2013 17:14, Jeff Gonis <[hidden email]> wrote:
> Hi everyone, > > I am currently working on getting the Squeak Jenkins server to perform > benchmarking and so far everything is going great except for one thing. When > I try to filein code implementing some benchmarks into a headless VM, it > just hangs. If I filein the same file to a non-headless VM everything works > just fine. > > Seeing as how things only blow up when I am running headless, debugging is > made somewhat more complicated. > > I was wondering if anyone had some advice on getting better debug > information from a headless VM, besides explicit log statements? I was also > wondering if this sort of problem is ringing any bells for anyone on the > list. I don't really have a good grip on how filein works either, so any > pointers would be greatly appreciated. Would filein be attempting to send ui > messages that are failing? I didn't see any user input requests when I filed > into a normal VM, so I don't think it is waiting on a response. Any help is > appreciated. SyntaxErrors in your scripts will bite. Run the image headful until you're sure you've got it right. Wrapping your script in an [] on: Error do: [:e | "print to stdout" ] is a good idea, but doesn't save you from a SyntaxError. We'll probably have this problem until we (a) rewrite the load logic and (b) have something like Pharo's CommandLineUIManager. Also, don't ever put ! characters in your load scripts. Even if they're in a string. See http://bugs.squeak.org/view.php?id=7732 frank > Thanks for your time, > Jeff > > > > |
In reply to this post by Eliot Miranda-2
On Thu, Feb 07, 2013 at 12:09:27PM -0800, Eliot Miranda wrote:
> On Thu, Feb 7, 2013 at 11:18 AM, Jeff Gonis <[hidden email]> wrote: > > > That is awesome. Getting visibility into the image is exactly what I have > > been grappling with, so this is a big help. > > > > > > On Thu, Feb 7, 2013 at 12:05 PM, Bob Arning <[hidden email]> wrote: > > > >> If you can't see what's going on inside the headless image, getting > >> some sort of picture would be a start. Try doing this in the image and save > >> it: > >> > >> [ > >> [ > >> f _ FileDirectory default fileNamed: 'allMyProcesses'. > >> f nextPutAll: Time now asString; cr. > >> Process allInstances do: [ :p | > >> p suspendedContext ifNotNilDo: [ :ctxt | f nextPutAll: > >> 'priority: ',p priority asString; cr; > >> nextPutAll: ctxt longStack; cr; cr] > >> ]. > >> f close. > >> (Delay forSeconds: 30) wait > >> ] repeat > >> ] forkAt: 60 > >> > >> the output might point you to where things stand. > >> > > > and with the Cog VMs on Mac and Linux sending SIGUSR1 to the VM will get it > to print out the same to the console (provided you start the VM from a > console). > Or if you are using an interpreter VM and you have OSProcess installed, this turns on a similar feature: "OSProcess accessor setPrintAllStacksOnSigUsr1" Although I have to say that I like Bob Arning's suggestion, since it will produce a log file with something possibly useful at the end of the file after the image hangs. Dave |
Free forum by Nabble | Edit this page |