Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Power PC, code crashes with query corrupt stack #4205

Closed
vicuna opened this issue Feb 14, 2007 · 2 comments
Closed

Power PC, code crashes with query corrupt stack #4205

vicuna opened this issue Feb 14, 2007 · 2 comments
Labels
bug

Comments

@vicuna
Copy link

vicuna commented Feb 14, 2007

Original bug ID: 4205
Reporter: @johnwhitington
Status: closed (set by @xavierleroy on 2007-11-10T12:49:01Z)
Resolution: unable to duplicate
Priority: normal
Severity: crash
Version: 3.09.3
Category: misc

Bug description

A large (25,000) line program, after some simple changes in Ocaml code, now crashes with the errors shown below. It's not pure ocaml, but the changes are not relevant to the C parts, which have been stable for a long time.

Reverting the source code prevents the error. But changes made to the source seem to arbitrarily provoke this problem. It's getting very fragile!

I can provide a binary (easily) or source (with effort) privately.

OS X Error report upon running executable.

Exception: EXC_SOFTWARE (0x0005)
Code[0]: 0x00000001
Code[1]: 0x000491e0

Thread 0 Crashed:
0 com.yourcompany.WxCoherence 0x000491e0 camlPolygon__new_was_sm_1206 + 644
1 com.yourcompany.WxCoherence 0x000495a0 camlPolygon__new_was_sm_subdivide_1205 + 744

Thread 0 crashed with PPC Thread State 64:
srr0: 0x00000000000491e0 srr1: 0x000000000202f030 vrsave: 0x0000000000000000
cr: 0x44000448 xer: 0x0000000000000006 lr: 0x00000000000490d8 ctr: 0x0000000000040e74
r0: 0x00000000000495a0 r1: 0x00000000bffff4d0 r2: 0x00000000003a4e9c r3: 0x0000000000000099
r4: 0x0000000000000078 r5: 0x000000000000001e r6: 0x000000000000003d r7: 0x000000000103dbf4
r8: 0x0000000000000005 r9: 0x000000000000009d r10: 0x0000000000000003 r11: 0x0000000000340000
r12: 0x0000000000000000 r13: 0x00000000bffffa48 r14: 0x0000000000000021 r15: 0x0000000000006f44
r16: 0x0000000000000021 r17: 0x00000000007e8818 r18: 0x0000000000000085 r19: 0x000000000103dcfa
r20: 0x0000000000000106 r21: 0x0000000000000079 r22: 0x000000000000f300 r23: 0x0000000000000083
r24: 0x0000000000000005 r25: 0x0000000000000005 r26: 0x00000000007e86e4 r27: 0x000000000000009d
r28: 0x000000000000009e r29: 0x00000000bffff820 r30: 0x00000000007cf000 r31: 0x00000000007e8670

GDB output from XCode:

(gdb) run
[Switching to process 12359 local thread 0x1207]
Running…
...
Program received signal: "EXC_SOFTWARE".
Previous frame inner to this frame (corrupt stack?)
Previous frame inner to this frame (corrupt stack?)
@vicuna
Copy link
Author

vicuna commented Feb 14, 2007

Comment author: @johnwhitington

I should have said: It's native code.

@vicuna
Copy link
Author

vicuna commented Feb 25, 2007

Comment author: @xavierleroy

I'm willing to investigate if you send me (Xavier.Leroy@inria.fr) a repro
case with sources. It can be pretty big; the important thing is that it
reproduces the crash.

The "corrupt stack" in gdb does not mean much: ocamlopt has its own conventions
for maintaining stack frames, conventions which gdb does not understand.

My guess at this point would be an incorrect GC root registration in your C stub
code. This can lead to intermittent crashes that are triggered by minor variations in the allocation pattern of the whole program.

@vicuna vicuna closed this as completed Nov 10, 2007
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@vicuna