Opened 9 years ago

Closed 9 years ago

#5177 closed bug (fixed)

Segfault in reportCCSProfiling

Reported by: dankna Owned by: simonmar
Priority: high Milestone: 7.2.1
Component: Profiling Version: 7.1
Keywords: Cc: dankna@…
Operating System: MacOS X Architecture: x86_64 (amd64)
Type of failure: Runtime crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

The test case is rather hard to reduce; sorry about that. I can provide my entire program on request, but it's hard to build, too, due to its polyglot nature. It may be relevant to know that I am running Haskell as a library from an Objective C main program. This does reproduce for me, so I can try further experiments if anyone can suggest any. The crash happens only when -O2 is turned on, not when only -O is. It also does not happen if -O2 and -funbox-strict-fields are on

My version is a GHC that I built myself from git; it comes up as 7.1.20110504-x86_64. I am running on OS X 10.6.7 with XCode 4. Here is a stack trace produced by gdb:

#0  0x00007fff83fac120 in strlen ()
#1  0x00007fff83fb7b1c in __vfprintf ()
#2  0x00007fff83ff8dcb in vfprintf_l ()
#3  0x00007fff83ff8d4e in fprintf ()
#4  0x0000000100250775 in reportCCSProfiling ()

Change History (6)

comment:1 Changed 9 years ago by dankna

Cc: dankna@… added

comment:2 Changed 9 years ago by simonmar

Milestone: 7.2.1
Priority: normalhigh

Since you're building GHC yourself, can you add the debug_p way in your build.mk:

GhcRTSWays += debug_p

rebuild the RTS (cd rts; make fast) and then relink your program with -debug. That should give a better stack trace.

comment:3 Changed 9 years ago by simonmar

Status: newinfoneeded

comment:4 Changed 9 years ago by dankna

Status: infoneedednew

Okay, so I did this. The stack trace wasn't any more useful (everything outside the reportCCSProfiling frame was my Objective-C main program or Apple's Cocoa code), but source-level debugging worked, so I was able to track down the problem.

Turns out it was a misusage on my part, rather than a GHC bug, but it should be documented so nobody else has this confusion. The issue was that the memory I had passed to hs_init() was not my real argc and argv, but rather a massaged version that I had dynamically allocated, and was freeing immediately after hs_init() returns. Since the code that outputs the profiling data assumes that memory is statically allocated and therefore still valid, I was getting intermittent crashes.

comment:5 Changed 9 years ago by simonmar

Owner: set to simonmar

I'll fix this - it's bad for hs_init to require that you keep the memory for argv around until hs_exit.

comment:6 Changed 9 years ago by simonmar

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.