Berkeley Unified Parallel C (UPC). Debugging with the GNU gdb C debbuger. Call stack
Good health!
Unified Parallel C (UPC) is an extension of the C language designed for high-performance computing on large-scale parallel machines. The language represents a single program model for systems with shared and shared memory. The number of parallelism is fixed at the start of the program, usually with one thread per processor core.
» UPC official website
» Berkeley UPC official website
In the last article, Installing in the Windows and Linux environment, describes how to perform a UPC installation, but the important issue of using debugging was not disclosed. It often happens that a program crashes if memory is incorrectly allocated somewhere or the array dimension is exceeded.
What can be done in this situation to narrow the place of the search? About this in the current article.
For a long time, I avoided learning to debug, because already had to do programming. Instead of debugging, I logged in detail enough about the actions of each stream through printf. However, the matter is overshadowed by the fact that the UPC program is translated to C and in the general case is not interpretable. If some line was successfully executed (by logs), and the next log did not happen, then it is not a fact that the error is between logged lines! Very often, the error of the “future” affects the current situation and causes the program to collapse in a completely different place.
')
If it’s OK with English, full debugging information can be found on the official Debugging Berkeley UPC applications page.
If you have a mailbox in the university domain, then you can request a student license recommended by TotalView, if not, you can use the standard debugger C.
It is necessary to pay attention that after transferring to C the main () function will turn into user_main ().
The first is to use the special debug mode, you need to run upcc with the
There are several entry points to debugging. You can stop a thread with a specific number using the
Next, you need to run gdb in another console session from the folder with output compilation files and specify the stream PID
To continue the execution of the program, you must run the following code:
The program helpfully reports a line with an error:
To view the current breakpoint in more detail, you can use the command:
Who would have thought. I'm going to deal with indexes and allocated memory)) To find out the call stack, you can use the bt command
The call stack needs to be viewed from the bottom. The user program starts with user_main, then the calls go successively and you can see where and with what parameters the error occurs.
To exit debugging correctly, you need to continue further, after which you can make a
If for some reason the debugging processes are stuck, they can be killed with the help of the
The most popular gdb commands are:
And as usual,
Thank you for attention! I hope someone will come in handy
Unified Parallel C (UPC) is an extension of the C language designed for high-performance computing on large-scale parallel machines. The language represents a single program model for systems with shared and shared memory. The number of parallelism is fixed at the start of the program, usually with one thread per processor core.» UPC official website
» Berkeley UPC official website
In the last article, Installing in the Windows and Linux environment, describes how to perform a UPC installation, but the important issue of using debugging was not disclosed. It often happens that a program crashes if memory is incorrectly allocated somewhere or the array dimension is exceeded.
*** 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 (cast taken)
What can be done in this situation to narrow the place of the search? About this in the current article.
For a long time, I avoided learning to debug, because already had to do programming. Instead of debugging, I logged in detail enough about the actions of each stream through printf. However, the matter is overshadowed by the fact that the UPC program is translated to C and in the general case is not interpretable. If some line was successfully executed (by logs), and the next log did not happen, then it is not a fact that the error is between logged lines! Very often, the error of the “future” affects the current situation and causes the program to collapse in a completely different place.
')
If it’s OK with English, full debugging information can be found on the official Debugging Berkeley UPC applications page.
If you have a mailbox in the university domain, then you can request a student license recommended by TotalView, if not, you can use the standard debugger C.
It is necessary to pay attention that after transferring to C the main () function will turn into user_main ().
The first is to use the special debug mode, you need to run upcc with the
-g option. This means that a special UPC configuration will be launched from the dbg subfolder. In order to be able to see specific lines of code, you need to save temporary files with sources at compile time with the -save-temps parameter: upcc ./Pack_Polycubes.upc -o Pack_Polycubes -pthreads <b>-save-temps -g</b> There are several entry points to debugging. You can stop a thread with a specific number using the
-freeze[=<thread_id>] parameter, or you can just stop by mistake using -freeze-on-error : upcrun -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
has been configured with these optional features enabled:
debugging tracing statistical collection debugging malloc
This is usually
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 output compilation files and specify the stream PID
gdb Pack_Polycubes.o 31257 GNU 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 execution of the program, you must run the following code:
(gdb) set gasnet_frozen = 0 (gdb) continue The 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 view the current breakpoint in more detail, you can use the command:
(gdb) list 1060 // Row-to-Column Multiplication
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'm going to deal with indexes and allocated memory)) To find out the call stack, you can use the bt command
(gdb) bt # 0 0x00000000004289f8 in MultiplyMatrixPackSpace (Result = 0x26274ac, Matrix = 0x2696340, CurPackSpace = 0x7ffd81634020)
# 1 0x0000000000428680 in CheckIndependancePS (CurPackSpace = 0x7ffd81634020) at ./Pack_Polycubes.upc:1032
# 2 0x0000000000428430 in AddIndependentPackSpace (CurPackSpace = 0x7ffd81634020) at ./Pack_Polycubes.upc:1011
...
# 8 0x000000000042e21 in ExplorePackSpaces () at ./Pack_Polycubes.upc:922
# 9 0x00000000004244c5 in user_main (argc = 4, argv = 0x7ffd816344e8) at ./Pack_Polycubes.up around14 ...
The call stack needs to be viewed from the bottom. The user program starts with user_main, then the calls go successively and you can see where and with what parameters the error occurs.
To exit debugging correctly, you need to continue further, after which you can make a
quit . (gdb) continue Continuing.
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 with the help of the
kill command from another console window, but in Rosa it is simpler with the help of Ctrl ^ C.The most popular gdb commands are:
break [file:]functiop- set abreak [file:]functiopon the functionbtcall stackprint expr- display the value of the expression- continue program executionnext- execute the next line of the program (jump over)step- step inside the program linelist- view the current break linehelp- call helpquit- exit
And as usual,
man gdbThank you for attention! I hope someone will come in handy
Source: https://habr.com/ru/post/317196/
All Articles