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] -B enable UI node highlighting -c disable lookaside cache -d enable memory debug -E set error print level (default = 3) -F load a module definition file -i set read delay threshhold (default = 0.05) -l toggle logging to dx.log (default = off) -L force a license type (runtime or develop) -m mark module execution times -M limit global memory (default = 0) -p number of processors (default = 1) -P toggle processor status (default = off) -r turn on remote execution -R started with rsh but not in remote mode -S intra graph serialization (default = on) -t enable exec timing & printing -T trace module executions -u disable parse ahead (for leak detection) -v display executive version number -V enables 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, 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 > > > > > > > > > > > > > > > > > >
