Hi, I'm seeing many segfaults (around 20 to 30% of the time) when running Fuel builds on Linux. Everytime I see it it's caused by #copyStack (e.g. https://travis-ci.org/theseion/Fuel/jobs/345741310). AFAICT it happens more often (exclusively?) on 32 bit with Pharo 7 (latest VM + latest image). Any ideas? Cheers, Max
|
Hi Max,
On Sat, Feb 24, 2018 at 1:07 PM, Max Leske <[hidden email]> wrote:
Try and construct a test case that crashes without user interaction. i.e. something that starts up with a known image, supplying a script to load via Fuel. Once this crashes reliably debugging is easy. Otherwise its very hard. As soon as you have the crashing test case let me know and I'll take a look. Ideally it would run on Mac OS X. _,,,^..^,,,_ best, Eliot |
In reply to this post by Max Leske
Thanks Eliot. On 24 February 2018 at 22:15:21, [hidden email] ([hidden email]) wrote:
I've tried for the last two hours to come up with a reliable way of triggering the segfault but haven't had any luck. I can only reproduce it on Linux, not macOS and I've only been able to force the segfault with using smalltalkCI: git clone https://github.com/hpi-swa/smalltalkCI.git && git clone https://github.com/theseion/Fuel.git && smalltalkCI/run.sh -s Pharo-alpha Fuel/.default.ston I used Ubuntu 17.04 (32-bit), TravisCI uses 14.04.5 (64-bit). Maybe there's a way I can extract some information you can use? And then I'll just play mole whacking until I trigger it... :) Cheers, Max |
Hi Max,
On Sat, Feb 24, 2018 at 2:57 PM, Max Leske <[hidden email]> wrote:
There should at least be a crash.dmp file that should contain a reasonably informative stack trace and register set. What does that show you? When you combine the crash.mp output with a gdb session you can find the offending instruction and relate that to the register set in crash.mp to find out the instruction that caused the crash. Tracing back form that isn't necessarily trivial but at least one has started :-)
_,,,^..^,,,_ best, Eliot |
Free forum by Nabble | Edit this page |