Re: [opendx-dev] is there a way to use gdb to trace codes in /exec/dxmods?
Thank you very much for your help, David. However I still cannot connect the UI to the dxexec using your suggestion. I simply could not find the info about the port number. I have tried the default 1900 and 1920 (as in the uipp/dxuilib/DXApplication.C) and none of them work. In addition, I do want to know how the codes in exec/dxmods interact with the codes in /uipp/dxui and /uipp/dxuilib, paticularlly for the interactors. Please advise and many many thanks! Jack The following is the log of the session: GNU DDD 3.3.1 (i386-redhat-linux-gnu), by Dorothea L(gdb) list scalar.c:1 Line 1 of scalar.c is at address 0x8117a50 m_Scalar but contains no code. (gdb) break scalar.c:19 breakpoint_create_event Breakpoint 1 at 0x8117a56: file scalar.c, line 19. (gdb) run -R -b Incorrectly built binary which accesses errno, h_errno or _res directly. Needs to be fixed. breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event [New Thread 16384 (LWP 22809)] breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event breakpoint_delete_event /usr/local/dx/bin/dxexec: invalid option -- b Open Visualization Data Explorer More Info at www.research.ibm.com/dx and www.opendx.org Version - 4.2.0 usage: /usr/local/dx/bin/dxexec [-B][-c][-d][-E #][-F file][-i #][-l][-m][-M #][-p #][-P][-r][-R][-S][-t][-T][-u][-v] -Benable UI node highlighting -cdisable lookaside cache -denable memory debug -Eset error print level(default = 3) -Fload a module definition file -iset read delay threshhold(default = 0.05) -ltoggle logging to dx.log (default = off) -Lforce a license type (runtime or develop) -mmark module execution times -Mlimit global memory (default = 0) -pnumber of processors (default = 1) -Ptoggle processor status (default = off) -rturn on remote execution -Rstarted with rsh but not in remote mode -Sintra graph serialization(default = on) -tenable exec timing printing -Ttrace module executions -udisable parse ahead (for leak detection) -vdisplay executive version number -Venables printing of executive DXDebug messages Program exited with code 02. breakpoint_delete_event breakpoint_delete_event (gdb) On Tue, 18 Nov 2003, David L Thompson wrote: Here is the typical way I debug stuff. From a shell you need to set some environment variables up since you won't be launching with the dx script. So start out with: setenv DXROOT /usr/local/dx setenv DXDATA /usr/local/dx/samples/data setenv DXMACROS /usr/local/dx/samples/macros Now from that shell you're pretty good to go for launching the exec. ddd /usr/local/dx/bin_intelnt/dxexec Now from within ddd, set your breakpoints and then you need to run it with -R -b flags. This will display the port in the message window below that the server is running on (typically port 1900.) Now from what you were saying, you don't need to debug the UI. So you can just launch the ui with dx -uionly Once the UI is running, then you need to go to the connect menu and connect to the already running server on port 1900 (the default). If for some reason you need to debug the UI C++ code, then you can do something similar to above. You might want to use dx -echo flag to see what real executables and flags are being used. Original Message From: Jack Chang Date: Tue 11/18/03 14:06 To: David L Thompson Cc: opendx deveoper network Subject: Re: [opendx-dev] is there a way to use gdb to trace codes in /exec/dxmods? Thanks a lot for your help, David. I tried the following but was not able to connect the UI to the running server: ddd dxui . once it runs, I set up some break points and tehn hit run to start the dx server dx -uionly . I then try to connect to the existing running server but have no idea which port I should connect to (the default 1900 does not work) Please advise and thank you very much for your help and patience! Jack On Tue, 18 Nov 2003,
Re: [opendx-dev] is there a way to use gdb to trace codes in /exec/dxmods?
Thanks a lot for your help, David. I tried the following but was not able to connect the UI to the running server: ddd dxui . once it runs, I set up some break points and tehn hit run to start the dx server dx -uionly . I then try to connect to the existing running server but have no idea which port I should connect to (the default 1900 does not work) Please advise and thank you very much for your help and patience! Jack On Tue, 18 Nov 2003, David L Thompson wrote: What you are seeing is the separation of the two. The user interface communicates to the exec over a socket, thus there is no code in the UI that ever runs to do a Isosurface per se, instead the exec tells the UI that it is running and when it is finished as a separate process. In order to debug with the UI and the exec, you will need to start an exec using ddd or gdb, then start a UI (dx -uionly), and then go to the connect menu and select connect to running server. David Original Message From: Jack Chang Date: Tue 11/18/03 12:46 To: David L Thompson Cc: opendx deveoper network Subject: Re: [opendx-dev] is there a way to use gdb to trace codes in /exec/dxmods? Thanks for the suggestion, however, I have already had a -ggdb flag on CFLAGS. The strange thing is that if I run ddd exec, I can see all the source files within /exec (includes dxmods) but not uipp (which makes sense since dxexec does not use the GUI stuff). However, if I run ddd dxui, I can only see files within the /uipp directories but not the codes in the /exec directories (which does not make sense to me since dxui still need to access dx kernel defined in /exec), so Jack On Tue, 18 Nov 2003, David L Thompson wrote: If you can debug some but not others it just seems that the debug flag wasn't on when you compiled your modules. Drop to src/exec/dxmods, edit the Makefile and add - g to CFLAGS. Then make clean, and make. Original Message From: Jack Chang Date: Tue 11/18/03 9:13 To: opendx deveoper network Subject:[opendx-dev] is there a way to use gdb to trace codes in /exec/dxmods? Hello, I am curious if there is a way to use gdb to trace codes in /exec/dxmods? Is there a simple compilation/linking switch within the makefile which will enable me to do so? I can trace most of the dx codes using the debugger except the stuff within the /exec/dxmods. Please advise and thank you very much for your help! Sicnerely, Jack Chang Pittsburgh Supercomputing Center
