Stack overflow in be.exe
I'm compiling a relatively complex ported program in CUDA and running into various compiler bugs.

The first bug I was able to fix myself and I'll explain the procedure. The problem was in be.exe, which crashed and caused the generic Windows exception dialog. Clicking "debug" and opening up VS showed there was a stack overflow. (I swear to god, this is the first time that pointless dialog ever helped me.) Researching the problem, it turned out that the editbin utility that comes with VS can be used to change an executable's stack size using a command such as 'editbin /STACK:20000000 be.exe'. To use this executable, open the VS Command Prompt and navigate to the CUDA bin directory. I had to set a 20MB stack to compile my application.

The second bug, this time in an even more complex program, I cannot fix. (It compiles and runs fine in emulation mode however.) The output is:
Signal: caught in VHO Processing phase.
<input>(0): Error: Signal caught in phase VHO Processing -- processing aborted
nvopencc ERROR: C:\CUDA\bin/../open64/lib//be.exe returned non-zero status 3

If I cut out most of the code from that second application, it still doesn't compile but reports a rather different error:
Internal error
nvcc error : 'ptxas' died with status 0xC0000005 (ACCESS_VIOLATION)

Please let me know to whom I can send a bug report.
I'm compiling a relatively complex ported program in CUDA and running into various compiler bugs.



The first bug I was able to fix myself and I'll explain the procedure. The problem was in be.exe, which crashed and caused the generic Windows exception dialog. Clicking "debug" and opening up VS showed there was a stack overflow. (I swear to god, this is the first time that pointless dialog ever helped me.) Researching the problem, it turned out that the editbin utility that comes with VS can be used to change an executable's stack size using a command such as 'editbin /STACK:20000000 be.exe'. To use this executable, open the VS Command Prompt and navigate to the CUDA bin directory. I had to set a 20MB stack to compile my application.



The second bug, this time in an even more complex program, I cannot fix. (It compiles and runs fine in emulation mode however.) The output is:

Signal: caught in VHO Processing phase.

<input>(0): Error: Signal caught in phase VHO Processing -- processing aborted

nvopencc ERROR: C:\CUDA\bin/../open64/lib//be.exe returned non-zero status 3



If I cut out most of the code from that second application, it still doesn't compile but reports a rather different error:

Internal error

nvcc error : 'ptxas' died with status 0xC0000005 (ACCESS_VIOLATION)



Please let me know to whom I can send a bug report.

#1
Posted 08/12/2008 03:25 AM   
>> 'ptxas' died with status 0xC0000005 (ACCESS_VIOLATION)

This bug has already been discussed before! you may want to file a report with most minimalistic code that reproduces it!


btw, which CUDA version are you using? 1.0? 1.1? 2.0?

Did you check with the latest CUDA 2.0 -- probably they are all fixed.

If you are already using 2.0 only -- check with CUDA 1.1
>> 'ptxas' died with status 0xC0000005 (ACCESS_VIOLATION)



This bug has already been discussed before! you may want to file a report with most minimalistic code that reproduces it!





btw, which CUDA version are you using? 1.0? 1.1? 2.0?



Did you check with the latest CUDA 2.0 -- probably they are all fixed.



If you are already using 2.0 only -- check with CUDA 1.1

Ignorance Rules; Knowledge Liberates!

#2
Posted 08/12/2008 05:11 AM   
ok, I figured out the ACCESS_VIOLATION issue. I had two functions that were calling eachother. Because nvcc inlines everything, that wouldn't work. I wish it'd give an actual error message however.

So that still leaves the "signal caught in VHO Processing phase" and also this error message:
template.cpp3.i(572): Advisory: Cannot tell what pointer points to, assuming global memory space

I understand what it means, but the file and linenumber it points to is totally meaningless! I have no idea what piece of code is causing this (and I have to track this down, because most likely the pointer is to local mem). fn annoying!

p.s. yes, i'm using 2.0
ok, I figured out the ACCESS_VIOLATION issue. I had two functions that were calling eachother. Because nvcc inlines everything, that wouldn't work. I wish it'd give an actual error message however.



So that still leaves the "signal caught in VHO Processing phase" and also this error message:

template.cpp3.i(572): Advisory: Cannot tell what pointer points to, assuming global memory space



I understand what it means, but the file and linenumber it points to is totally meaningless! I have no idea what piece of code is causing this (and I have to track this down, because most likely the pointer is to local mem). fn annoying!



p.s. yes, i'm using 2.0

#3
Posted 08/12/2008 05:23 AM   
Was able to figure out the "Signal: caught in VHO Processing phase." crash also. The cause was a function pointer. (Since cuda must inline everything, this is a no-no.) This was also the reason for the unidentified pointers warning.

The method to figure all these things out was to comment out lines untill the compiler quicks choking. Except to anyone who will have to do this themselves, keep in mind that the problem is often not caused by the line just uncommented! You have to look at the variables, because you could be unmasking a line upstream that was being optimized out (because its results weren't being used).

Anyway, nvidia, NOT COOL! I know you keep hoping to get your compiler to work with real function calls any day now... But for now, you can't have your compiler crash (in various novel ways) every time inlining can't happen. PLEASE, YOU NEED ERROR MESSAGES! What kind of retarded compiler can't see it's being given a function pointer and report back that it can't process such a thing.
Was able to figure out the "Signal: caught in VHO Processing phase." crash also. The cause was a function pointer. (Since cuda must inline everything, this is a no-no.) This was also the reason for the unidentified pointers warning.



The method to figure all these things out was to comment out lines untill the compiler quicks choking. Except to anyone who will have to do this themselves, keep in mind that the problem is often not caused by the line just uncommented! You have to look at the variables, because you could be unmasking a line upstream that was being optimized out (because its results weren't being used).



Anyway, nvidia, NOT COOL! I know you keep hoping to get your compiler to work with real function calls any day now... But for now, you can't have your compiler crash (in various novel ways) every time inlining can't happen. PLEASE, YOU NEED ERROR MESSAGES! What kind of retarded compiler can't see it's being given a function pointer and report back that it can't process such a thing.

#4
Posted 08/12/2008 04:39 PM   
Scroll To Top