This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Steps to reproduce: - create SubProjects sample application - set Line breakpoints in all "hello" methods - set a Line BP at "Print Arguments..." block in main() - start debugging Result: Debugger stops at breakpoints in hello1() and hello2() and skip breakpoints in hello3() and hello4(). DBX console shows: ... (dbx) stop at "/export/home/pep/NbWeeklyTestingProjects/SubProjects_ss/main/main.cc":46 (dbx) stop at "/export/home/pep/NbWeeklyTestingProjects/SubProjects_ss/hello1lib/hello1.cc":33 (dbx) stop at "/export/home/pep/NbWeeklyTestingProjects/SubProjects_ss/hello2lib/hello2.cc":33 (dbx) stop at "/export/home/pep/NbWeeklyTestingProjects/SubProjects_ss/hello3lib/hello3.cc":33 dbx: cannot find object file corresponding to "/export/home/pep/NbWeeklyTestingProjects/SubProjects_ss/hello3lib/hello3.cc" (dbx) stop at "/export/home/pep/NbWeeklyTestingProjects/SubProjects_ss/hello4lib/hello4.cc":33 dbx: cannot find object file corresponding to "/export/home/pep/NbWeeklyTestingProjects/SubProjects_ss/hello4lib/hello4.cc" ....
same behavior in SunStudio
Yes, SunStudio IDE behaves the same way (CR 6630788) but this does not mean that the bug should not be fixed. It looks very unfriendly if basic debugger features do not work correctly in provided samples.
posponed until we have dbx support in NB
move dbx related issues into dbx-gui component
mark issues as not fixed
This is an interesting bug. If you look higher up in the dbx console you will see: (dbx-0) debug /var/tmp/SubProjects_3/main/dist/Debug/SunStudio-Solaris-Sparc/main Reading /var/tmp/SubProjects_3/main/dist/Debug/SunStudio-Solaris-Sparc/main Reading /usr/lib/ld.so.1 terminating signal 9 SIGKILL dbx: warning: 'stop' ignored -- while doing rtld handshake This usually means that the working directory wasn't set right when 'debug' was issued so the dynamic linker failed to find libhello3lib.so and libhello4lib.so. No .so no symbol table, no breakpoints. A cd needs to be issued prior to 'debug'. This has been brought up in CR 4983422 and one other one (and I thought I had fixed it...) so it needs to be looked at again. However ... one shouldn't have to depend on the working directory being set right. If I cd to /var/tmp/SubProjects_3/main/dist/Debug/SunStudio-Solaris-Sparc and run main it won't run either. So I'd say that the application is built incorrectly. It's not useful to run an application only in the directory it was built. For example, it should be compiled with -R) There's quite more to this so I'm filing a separate BZ against CND. Then, there's another take on this. In general the shared libraries are available to the application and dbx at startup and debug time: bash@parra: dbx /home/ivan/bin/amd64-Linux/dbx Reading /home/ivan/bin/amd64-Linux/dbx Reading /lib64/ld-linux-x86-64.so.2 Reading /lib64/libdl.so.2 Reading /lib64/libm.so.6 Reading /lib64/libc.so.6 This is not true for gdb: $ gdb /home/ivan/bin/amd64-Linux/dbx GNU gdb 6.6 ... (gdb) break main Breakpoint 1 at 0x52b720: file dbxmain.cc, line 2690. (gdb) break printf Function "printf" not defined. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) gdb calls these "virtual" breakpoints. Now dbx doesn't have virtual breakpoints. It requires that all symbol tables be available before breakpoints will take. In general this is not an issue because dbx goes through the trouble of reading the primary .so's symbol tables. It's only an issue if .so's are dlopen()ed That is really an RFE and it has to be implemented in dbx.
bug #180301 addresses the proper use of -R issue.
details: http://lessing.sfbay.sun.com/hg/toolshg/rev/0d02e2a54b1d