December 14, 2016 at 08:27Berkeley Unified Parallel C (UPC). Debugging with GNU gdb C debbuger. Call stack
- Tutorial
Good health!
Unified Parallel C (UPC) is a C language extension designed for high-performance computing on large-scale parallel machines. The language represents a single programming model for systems with shared and shared memory. The amount of parallelism is fixed at the start of the program, usually with one thread per processor core.
» Official UPC Website
» Official Berkeley UPC Website
In a previous article, Installation on Windows and Linux describes how to perform a UPC installation, but the important issue of using debugging remains unresolved. A program crashes very often if memory is allocated incorrectly somewhere or the array is oversized
What can be done in this situation to narrow the search? About this in the current article.
For a long time I avoided learning about debugging, as already needed to do programming. Instead of debugging, I logged in enough detail through printf for the actions of each thread. However, the matter is overshadowed by the fact that the UPC program is translated into C and in the general case is not interpreted. If some line was successfully executed (by logs), and the next log did not happen, then it is not a fact that there is an error between the logged lines! Very often, the error of the “future” affects the current situation and causes the program to crash in a completely different place.
If everything is in order with English, full debugging information can be found on the official page of Debugging Berkeley UPC applications .
If you have a mailbox in the university’s domain, then you can request a student license of the recommended TotalView, if not, you can use the regular debugger C.
It should be noted that after translating to C, the main () function will turn into user_main ().
First, to use the special debugging mode, you need to run upcc with the parameter
There are several debug entry points. You can stop the stream with a specific number using the parameter , or you can simply stop by mistake with :
Next, you need to run gdb in another console session from the folder with the output compilation files and specify the PID of the stream
To continue the program, you must run the following code:
The program helpfully reports a line with an error:
To see the current breakpoint in more detail, you can use the command:
Who would have thought. I’ll go to deal with indexes and allocated memory)) To find out the call stack, you can use the bt command
The call stack must be viewed from the bottom. The user program starts with user_main, then calls are made sequentially and you can see in what place and with what parameters the error occurs.
To correctly exit debugging, you need to continue further, after which you can do it
If for some reason the debugging processes are stuck, they can be killed using the command
The most requested gdb commands:
And as usual,
Thank you for your attention! I hope someone comes in handy
Unified Parallel C (UPC) is a C language extension designed for high-performance computing on large-scale parallel machines. The language represents a single programming model for systems with shared and shared memory. The amount of parallelism is fixed at the start of the program, usually with one thread per processor core. » Official UPC Website
» Official Berkeley UPC Website
In a previous article, Installation on Windows and Linux describes how to perform a UPC installation, but the important issue of using debugging remains unresolved. A program crashes very often if memory is allocated incorrectly somewhere or the array is oversized
*** Caught a fatal signal: SIGSEGV (11) on node 0/1
NOTICE: Before reporting bugs, run with GASNET_BACKTRACE = 1 in the environment to generate a backtrace.
Segmentation error (snapshot taken)
What can be done in this situation to narrow the search? About this in the current article.
For a long time I avoided learning about debugging, as already needed to do programming. Instead of debugging, I logged in enough detail through printf for the actions of each thread. However, the matter is overshadowed by the fact that the UPC program is translated into C and in the general case is not interpreted. If some line was successfully executed (by logs), and the next log did not happen, then it is not a fact that there is an error between the logged lines! Very often, the error of the “future” affects the current situation and causes the program to crash in a completely different place.
If everything is in order with English, full debugging information can be found on the official page of Debugging Berkeley UPC applications .
If you have a mailbox in the university’s domain, then you can request a student license of the recommended TotalView, if not, you can use the regular debugger C.
It should be noted that after translating to C, the main () function will turn into user_main ().
First, to use the special debugging mode, you need to run upcc with the parameter
-g. This means that a special UPC configuration will be started from the dbg subfolder. In order to be able to see specific lines of code, it is necessary to save temporary files with source codes during compilation using the parameter -save-temps:upcc ./Pack_Polycubes.upc -o Pack_Polycubes -pthreads -save-temps -gThere are several debug entry points. You can stop the stream with a specific number using the parameter , or you can simply stop by mistake with :
-freeze[=] -freeze-on-errorupcrun -n 1 -freeze-on-error ./Pack_Polycubes- WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING
This application was built from a Berkeley UPC installation that
was configured and built with these optional features enabled:
debugging tracing statistical collection debugging malloc
This usually has a SERIOUS impact on performance, so you should NOT
trust any performance numbers reported in this program run !!!
To suppress this message, pass '-quiet' to the upcrun command or set
the UPC_NO_WARN or UPC_QUIET environment variables.
- UPCR: UPC thread 0 of 1 on Rosa-VB (pshm node 0 of 1, process 0 of 1, pid = 31257)
Hello, I am 0 of 1.
...
*** Caught a fatal signal: SIGSEGV (11) on node 0/1
Process frozen for debugger: host = Rosa-VB pid = 31257
To unfreeze, attach a debugger and set 'gasnet_frozen' to 0, or send a SIGCONT
Next, you need to run gdb in another console session from the folder with the output compilation files and specify the PID of the stream
gdb Pack_Polycubes.o 31257GNU gdb (Linaro GDB) 7.7.1_2014.06_1-10 ()
Copyright © 2014 Free Software Foundation, Inc.
...
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00007f0afab16cd0 in __nanosleep_nocancel () from /lib64/libc.so.6
To continue the program, you must run the following code:
(gdb) set gasnet_frozen = 0
(gdb) continueThe program helpfully reports a line with an error:
Program received signal SIGSEGV, Segmentation fault.
0x00000000004289f8 in MultiplyMatrixPackSpace (Result = 0x26274ac, Matrix = 0x2696340, CurPackSpace = 0x7ffd81634020)
at ./Pack_Polycubes.upc:1065
1065 Result [row] [col] = 0;
To see the current breakpoint in more detail, you can use the command:
(gdb) list1060 // Multiplication by the rule "row by column"
1061 for (row = 0; row <Params.Demension; row ++)
1062 {
1063 for (col = 0; col <Params.Demension; col ++)
1064 {
1065 Result [row] [col] = 0;
Who would have thought. I’ll go to deal with indexes and allocated memory)) To find out the call stack, you can use the bt command
(gdb) bt# 0 in MultiplyMatrixPackSpace 0x00000000004289f8 (Result = 0x26274ac, Matrix = 0x2696340, CurPackSpace = 0x7ffd81634020)
# 1 in CheckIndependancePS 0x0000000000428680 (CurPackSpace = 0x7ffd81634020) at ./Pack_Polycubes.upc:1032
# 2 0x0000000000428430 in AddIndependentPackSpace (CurPackSpace = 0x7ffd81634020) at ./Pack_Polycubes .upc: 1011
...
# 8 0x0000000000427e21 in ExplorePackSpaces () at ./Pack_Polycubes.upc:922
# 9 0x00000000004244c5 in user_main (argc = 4, argv = 0x7ffd816344e8) at ./Pack_Polycubes.upc:14
The call stack must be viewed from the bottom. The user program starts with user_main, then calls are made sequentially and you can see in what place and with what parameters the error occurs.
To correctly exit debugging, you need to continue further, after which you can do it
quit.(gdb) continueContinuing
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
If for some reason the debugging processes are stuck, they can be killed using the command
killfrom another console window, but in Rosa it turns out easier with Ctrl ^ C. The most requested gdb commands:
break [file:]functiop- set a breakpoint on the functionbt- call the stackprint expr- display the value of the expressionс- continue the programnext- execute the next line of the program (jump)step- step inside the line of the programlist- view the current breakpointhelp- call for helpquit- exit
And as usual,
man gdbThank you for your attention! I hope someone comes in handy