www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Error when profiling

reply "Phil" <phil.j.ellison gmail.com> writes:
When trying to run my program with profiling enabled it dies 
before the first line of my main function runs. Everything works 
fine without profiling. I get the following stack trace:

  thread #1: tid = 0x38de4, 0x000000010008d985 
vision_entry`gc_malloc + 49, queue = 'com.apple.main-thread', 
stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
     frame #0: 0x000000010008d985 vision_entry`gc_malloc + 49
vision_entry`gc_malloc + 49:
-> 0x10008d985:  movq   (%rdi), %rbx
    0x10008d988:  callq  *0x60(%rbx)
    0x10008d98c:  popq   %rbx
    0x10008d98d:  movq   %rbp, %rsp
(lldb) thread backtrace
* thread #1: tid = 0x38de4, 0x000000010008d985 
vision_entry`gc_malloc + 49, queue = 'com.apple.main-thread', 
stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
   * frame #0: 0x000000010008d985 vision_entry`gc_malloc + 49
     frame #1: 0x00000001000908f5 vision_entry`_d_newclass + 117
     frame #2: 0x00000001000b4b28 
vision_entry`D3std9exception7bailOutFNaNfAyamxAaZv + 40
     frame #3: 0x00000001000b4d06 
vision_entry`D3std9exception14__T7enforceTbZ7enforceFNaNfbLAxaAyamZb 
+ 94
     frame #4: 0x00000001000c4df6 
vision_entry`D3std5stdio4File17LockingTextWriter6__ctorMFNcNeKS3std5stdio4FileZS3std5stdio4Fil
17LockingTextWriter 
+ 86
     frame #5: 0x00000001000c4f19 
vision_entry`D3std5stdio4File17lockingTextWriterMFZS3std5stdio4Fil
17LockingTextWriter 
+ 41
     frame #6: 0x0000000100002c74 
vision_entry`D3std5stdio4File15__T8writeflnTaZ8writeflnMFxAaZv + 
124 at stdio.d:1238
     frame #7: 0x0000000100000c06 vision_entry`_Dmain + 86 at 
stdio.d:2727
     frame #8: 0x000000010009060c 
vision_entry`D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv 
+ 40
     frame #9: 0x0000000100090551 
vision_entry`D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv 
+ 45
     frame #10: 0x00000001000905b1 
vision_entry`D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv + 45
     frame #11: 0x0000000100090551 
vision_entry`D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv 
+ 45
     frame #12: 0x00000001000904cd vision_entry`_d_run_main + 433
     frame #13: 0x0000000100000d29 vision_entry`main + 65
     frame #14: 0x00007fff883a45c9 libdyld.dylib`start + 1

Does anyone have any ideas of what could have caused this?
Jan 31 2015
parent "Nicholas Wilson" <iamthewilsonator hotmail.com> writes:
On Saturday, 31 January 2015 at 14:12:59 UTC, Phil wrote:
 When trying to run my program with profiling enabled it dies 
 before the first line of my main function runs. Everything 
 works fine without profiling. I get the following stack trace:

  thread #1: tid = 0x38de4, 0x000000010008d985 
 vision_entry`gc_malloc + 49, queue = 'com.apple.main-thread', 
 stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
     frame #0: 0x000000010008d985 vision_entry`gc_malloc + 49
 vision_entry`gc_malloc + 49:
 -> 0x10008d985:  movq   (%rdi), %rbx
    0x10008d988:  callq  *0x60(%rbx)
    0x10008d98c:  popq   %rbx
    0x10008d98d:  movq   %rbp, %rsp
 (lldb) thread backtrace
 * thread #1: tid = 0x38de4, 0x000000010008d985 
 vision_entry`gc_malloc + 49, queue = 'com.apple.main-thread', 
 stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
   * frame #0: 0x000000010008d985 vision_entry`gc_malloc + 49
     frame #1: 0x00000001000908f5 vision_entry`_d_newclass + 117
     frame #2: 0x00000001000b4b28 
 vision_entry`D3std9exception7bailOutFNaNfAyamxAaZv + 40
     frame #3: 0x00000001000b4d06 
 vision_entry`D3std9exception14__T7enforceTbZ7enforceFNaNfbLAxaAyamZb 
 + 94
     frame #4: 0x00000001000c4df6 
 vision_entry`D3std5stdio4File17LockingTextWriter6__ctorMFNcNeKS3std5stdio4FileZS3std5stdio4Fil
17LockingTextWriter 
 + 86
     frame #5: 0x00000001000c4f19 
 vision_entry`D3std5stdio4File17lockingTextWriterMFZS3std5stdio4Fil
17LockingTextWriter 
 + 41
     frame #6: 0x0000000100002c74 
 vision_entry`D3std5stdio4File15__T8writeflnTaZ8writeflnMFxAaZv 
 + 124 at stdio.d:1238
     frame #7: 0x0000000100000c06 vision_entry`_Dmain + 86 at 
 stdio.d:2727
     frame #8: 0x000000010009060c 
 vision_entry`D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv 
 + 40
     frame #9: 0x0000000100090551 
 vision_entry`D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv 
 + 45
     frame #10: 0x00000001000905b1 
 vision_entry`D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv + 
 45
     frame #11: 0x0000000100090551 
 vision_entry`D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv 
 + 45
     frame #12: 0x00000001000904cd vision_entry`_d_run_main + 433
     frame #13: 0x0000000100000d29 vision_entry`main + 65
     frame #14: 0x00007fff883a45c9 libdyld.dylib`start + 1

 Does anyone have any ideas of what could have caused this?
What is the source code of your main function? I ask because it looks like it did. frame 13 is C main. frames 12 - 8 are compiler generated. Frame 7 is D main.
     frame #7: 0x0000000100000c06 vision_entry`_Dmain + 86 at 
 stdio.d:2727
Frame 6 is std.stdio.writefln(...) Frame 5 is the acquisition of the locking text writer frame 4 is the constructor of the locking text writer. THIS IS WHERE THE EXCEPTION IS THROWN. as is evident by frame 3.
 vision_entry`D3std9exception14__T7enforceTbZ7enforceFNaNfbLAxaAyamZb 
 + 94
where the locking text writer is enforcing some condition. (possibly that it received the correct amour of arguments) Frame 2 is the enforce bailing out Frames 1 is bailout() throwing a _new_ exception. _d_newclass(exception) frame 0 is the gc_malloc attempting to allocate the memory for the exception. and hits a
 stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
 -> 0x10008d985:  movq   (%rdi), %rbx (rbx = *rdi)
null pointer somewhere. your main function looks like int main(string[] args) { writefln(...); // Double check whats going on here ... return 0; } try int main(string[] args) { try writefln(...); // Double check whats going on here catch(exception e) { writeln("caught some exception"); // alternatively use printf/puts if written also fails } ... return 0; } and you will see caught some exception instead of the stack trace. Are you profiling with an external profiler or using the compiler to emit profile statistics? My only guess is that there is a bug in the compiler's inserted profiling code. perhaps someone else will be able to help. Nic
Feb 01 2015