It seems that after ba7bb95 a seqfault was introduced to the 64bit Linux VM. With no image file the VM happily produces output. When providing an image file it immediately segfaults regardless of whether a display is provided or whether it runs headless. — |
Hi Patrick, > On Oct 17, 2019, at 3:00 AM, Patrick R <[hidden email]> wrote: > > It seems that after ba7bb95 a seqfault was introduced to the 64bit Linux VM. With no image file the VM happily produces output. When providing an image file it immediately segfaults regardless of whether a display is provided or whether it runs headless. > can you provide some more information? The crash.dmp file perhaps (please generate a fresh one so it contains only one or two crashes). Can you also possible boy disassemble the trampoline table to see what code is generated for s stack switch? Any of the send trampolines will do. To do this, in gdb put s breakpoint in interpret, run and proceed once, then call printTrampolineTable(), and then disassemble a send routine using a pair of addresses from the output. AdvThanksance — |
In reply to this post by David T Lewis
I'm trying to isolate the problem too. It might have something to do with my recent change to the dependencies, although I doubt it. I'll get back to you when I know more. — |
In reply to this post by David T Lewis
@eliotmiranda The commit that introduced the segfault is 30220af. — |
In reply to this post by David T Lewis
Can confirm @theseion 's finding after a bisect. The crash does not occur on debug builds for me, unfortunately. This is the stack I get in a production build:
— |
In reply to this post by David T Lewis
Same here:
It looks like the generated method got corrupted again... — |
In reply to this post by David T Lewis
However, if I use — |
In reply to this post by David T Lewis
May I close this one? — |
In reply to this post by David T Lewis
Sorry about that, I had interpreted your comment as a suggestion. Did you change the build process to use Clang instead of GCC? In that case I'll have to check again. I'll do that tonight. — |
In reply to this post by David T Lewis
Yes, see merged PR above. It's only a workaround, not a root cause analysis + solving. But since we have similar workaround already for Win64, we can live with it for a while... — |
In reply to this post by David T Lewis
I have to postpone this until at least tomorrow evening. Sorry. — |
In reply to this post by David T Lewis
Yes, using Clang fixes the segfault. Thanks Nicolas! If you already have such a workaround for Windows, I guess it would be a good idea to have a separate issue for reverting back to GCC (or whatever the plan might be then). You can go ahead and close this issue. — |
In reply to this post by David T Lewis
So I close the issue since the workaround works — |
In reply to this post by David T Lewis
Closed #433. — |
Free forum by Nabble | Edit this page |