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.

Bug 224840

Summary:	gdbserver: pause does not work on Linux
Product:	cnd	Reporter:	Egor Ushakov <gorrus>
Component:	Debugger	Assignee:	Maria Tishkova <mromashova>
Status:	NEW ---
Severity:	normal	CC:	Arkona_MatthiasMann, sehughes
Priority:	P3
Version:	8.0
Hardware:	PC
OS:	Windows 7 x64
Issue Type:	DEFECT	Exception Reporter:
Bug Depends on:	170488
Bug Blocks:

Description Egor Ushakov 2013-01-14 11:30:42 UTC

see bug 170488 for older information.
reported by sehughes@netbeans.org:

Unfortunately, I just tried netbeans-dev-201301120001 and I can confirm that
the pause bug had not been fixed (for me) in the scenario I describe in comment
34.

I'm not sure this is relevant, but the gdb I'm using is: GNU gdb (Wind River
Linux Sourcery G++ 4.3-242).  This is not something I can change as I need to
use the same toolchain for compile/link/debug.

Just so there's no confusion, here's what I'm doing:

1/ I create a test project with a single hello.c file:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char** argv) {
    int run = 1;
    while ( run ) {
        printf("hello world\n");
        sleep(1);
    }
    return (EXIT_SUCCESS);
}

2/ I build this using a cross compiler setup in code assistant (arm-linux-gcc)
this is a gcc-4.2.4 soft-float toolchain.  I've also tried other versions on
different ARM targets with the same issue (can't pause).

3/ I copy the executable to the target, which in this test is a Cirrus Logic
EDB9302 development board.

4/ On the target I run: gdbserver :1234 hello

5/ On the netbeans host, I set a breakpoint at the printf line.

6/ With the gdbserver plugin installed, I click on "attach debugger" and enter
the target IP address and port number

7/ As expected netbeans debugger stops at the breakpoint. If you click
continue, the target will continue again until it again hits the breakpoint.

8/ I now disable (or remove) the breakpoint and click on continue, execution
resumes as expected.

9/ I click on pause, nothing happens.  The host has lost control of the target.
 The only way to get control back again is to find the pid of the host gdb
executable and send it a SIGINT at the command line

Comment 1 Egor Ushakov 2013-04-30 13:41:05 UTC

*** Bug 224908 has been marked as a duplicate of this bug. ***

Comment 2 Egor Ushakov 2013-04-30 13:41:52 UTC

from the bug 224908:
I'm using Netbeans on Linux to debug a NiosII (Softcore CPU from Altera)
system.

Product Version: NetBeans IDE Dev (Build 201301120001)
Java: 1.7.0_11; Java HotSpot(TM) 64-Bit Server VM 23.6-b04
Runtime: Java(TM) SE Runtime Environment 1.7.0_11-b21
System: Linux version 2.6.38-16-generic running on amd64; UTF-8; de_DE (nb)

This uses a nios2-gdb-server which maintains the JTAG connection, and a
nios2-elf-gdb together with the gdbserver plugin of Netbeans. The attach
command is "remote 127.0.0.1:1234".

The problem is that the pause button in Netbeans does not work.
When I manually send a "kill -s INT <pid-of-nios2-elf-gdb>" Netbeans shows a
"DS1008.elf - Signal Caught" pop up:
Signal received: SIGTRAP (Trace/breakpoint trap)
For program DS1008.elf, pid -1

After pressing "Discard & Pause" the program is paused and I can debug it as
expected.

Comment 3 nathanh 2014-01-29 19:43:00 UTC

I have this issue when using Netbeans 7.4 and Netbeans 8.0.
My Setup is:
Dev Platform.: Windows 7, gdb - STM 7.4
Target: STi7109
The PAUSE button does not work and I can not interrupt the the "Debugger Console" session using Ctrl-C. Note that it does work using other IDEs (Insight).
Not sure what logs you need. Here is the debug console

--

This log is saved to: C:\Users\user\AppData\Local\Temp\gdb-cmds2776695486252539249.log
NB build: 201401290001
~"GNU gdb (STMicroelectronics Base) 7.4-ST-1.0 [build Nov  5 2012]\n"
~"Copyright (C) 2012 Free Software Foundation, Inc.\n"
~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law.  Type \"show copying\"\nand \"show warranty\" for details.\n"
~"This GDB was configured as \"--host=i686-pc-mingw32 --target=sh-superh-elf\".\nFor bug reporting instructions, please see:\n"
~"<<file://doc/docbug.htm> in the installation>.\n"
(gdb) 
~"Working directory C:\\n"
(gdb) 

...

Comment 4 nathanh 2014-01-29 19:54:18 UTC

My guess is the SIGINT is being sent to the wrong gdb process. There are two, sh4gdb is setup in netbeans env, and sh4gdb spawns the other. I don't have any workaround of know how to send SIGINT via Windows a command:
     26       4      776       2644    25     0.02  15036 sh4gdb
    122      17    48368      52660   156    16.26   4632 sh-superh-elf-gdb

(In reply to nathanh from comment #3)
> I have this issue when using Netbeans 7.4 and Netbeans 8.0.
> My Setup is:
> Dev Platform.: Windows 7, gdb - STM 7.4
> Target: STi7109
> The PAUSE button does not work and I can not interrupt the the "Debugger
> Console" session using Ctrl-C. Note that it does work using other IDEs
> (Insight).
> Not sure what logs you need. Here is the debug console
> 
> --
> 
> This log is saved to:
> C:\Users\user\AppData\Local\Temp\gdb-cmds2776695486252539249.log
> NB build: 201401290001
> ~"GNU gdb (STMicroelectronics Base) 7.4-ST-1.0 [build Nov  5 2012]\n"
> ~"Copyright (C) 2012 Free Software Foundation, Inc.\n"
> ~"License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to
> change and redistribute it.\nThere is NO WARRANTY, to the extent permitted
> by law.  Type \"show copying\"\nand \"show warranty\" for details.\n"
> ~"This GDB was configured as \"--host=i686-pc-mingw32
> --target=sh-superh-elf\".\nFor bug reporting instructions, please see:\n"
> ~"<<file://doc/docbug.htm> in the installation>.\n"
> (gdb) 
> ~"Working directory C:\\n"
> (gdb) 
> 
> ...

Comment 5 digitallife 2014-02-04 13:51:04 UTC

Same bug on Win7 x64 Netbeans 7.4 and NetBeans IDE Build 201402030001. I also have Eclipse on the same machine using same gdb and GDBserver ant everything works correctly. I can upload gdb logs from Eclipse debug session if they are of any use.

It wuold be great to switch from Eclipse to Netbeans for embedded development, but so far this bug ruins all debugging process :(

Comment 6 nathanh 2014-02-04 14:06:08 UTC

If this issue affects you, make sure to vote on this bug to raise the priority.

Comment 7 henk89 2014-07-25 08:14:51 UTC

Could you please provide me with logs from both NetBeans and Eclipse sessions?

Comment 8 elcojacobs 2015-01-11 22:52:17 UTC

We are using NetBeans for ARM Cotex M3 development and remote debugging and I can report that this bug affects us too.

I am using Texane st-link and the gdbserver plugin to do hardware step debugging on the ARM target (the ST-LINK SWD hardware debugger). I'd be happy to follow any instructions to generate log files.

Comment 9 henk89 2015-01-22 13:35:39 UTC

(In reply to elcojacobs from comment #8)
> We are using NetBeans for ARM Cotex M3 development and remote debugging and
> I can report that this bug affects us too.
> 
> I am using Texane st-link and the gdbserver plugin to do hardware step
> debugging on the ARM target (the ST-LINK SWD hardware debugger). I'd be
> happy to follow any instructions to generate log files.

Am I right that you have troubles with debugging on Windows?

Comment 10 mdma 2015-01-22 13:44:47 UTC

(In reply to henk89 from comment #9)
> (In reply to elcojacobs from comment #8)
> > We are using NetBeans for ARM Cotex M3 development and remote debugging and
> > I can report that this bug affects us too.
> > 
> > I am using Texane st-link and the gdbserver plugin to do hardware step
> > debugging on the ARM target (the ST-LINK SWD hardware debugger). I'd be
> > happy to follow any instructions to generate log files.
> 
> Am I right that you have troubles with debugging on Windows?

Yes, that's correct - on Windows.  (Although it says Linux at the top of this bug, comment #3 also mentions windows, so we figured it was worthwhile giving you another datapoint.)

I hope you are able to look into it - it would be awesome to be able to pause the debugger. But if that's not possible, some pointers where we could look in the code to attempt a fix would be great!