Ticket #5177 (closed bug: fixed)

Opened 2 years ago

Last modified 2 years ago

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 Difficulty:
Test Case: Blocked By:
Blocking: Related Tickets:

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

Changed 2 years ago by dankna

  • cc dankna@… added

Changed 2 years ago by simonmar

  • priority changed from normal to high
  • milestone set to 7.2.1

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.

Changed 2 years ago by simonmar

  • status changed from new to infoneeded

Changed 2 years ago by dankna

  • status changed from infoneeded to new

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.

Changed 2 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.

Changed 2 years ago by simonmar

  • status changed from new to closed
  • resolution set to fixed

Fixed: changeset:a6e8418a71b14ef85ee7134be654689b17765f03

Note: See TracTickets for help on using tickets.