Codewarrior and QNX RTP 6.1, pdebug signal debugging problem

QNX Newsgroups (Archives) qdn.public.qnxrtp.devtools
1

Hi all!,

  1. We are running into some problem in debugging our signal handler with
    Codewarrior 2.1 and QNX RTP 6.1. The CodeWarrior SW will trap on the alarm
    signal once, then the apps will crash on the remote target. If I run the
    same apps manual with some printf in the signal handler, the apps will have
    no problems running.

  2. I have one developper using CodeWarrior 2.1, with the QNX SDK 2.11 ,
    and connecting to a QNX 2.11 PC without any problems. He is able to
    breakpoint into the is signal handler and CodeWarrior handles the alarm
    signals without any problems. If the same developer connects to a QNX RTP
    6.1 then we have some problems, and the apps crashes on the first signals
    coming in.

  3. At first I suspected library issues between the SDK 2.11 and the RTP 6.1,
    but I just received the new SDK 6.1 for windows that support QNX RTP 6.1.
    After installing the SDK, I am running into the same problems than 1. I
    suspect something was broken or repaired in pdebug on RTP 6.1 to cause this
    strange behavior.

any help or comments would be appreciated!!

Cheers!, Steph

2

Stephane Grenier <sgrenier@excalibur.com> wrote:

Hi all!,

  1. We are running into some problem in debugging our signal handler with
    Codewarrior 2.1 and QNX RTP 6.1. The CodeWarrior SW will trap on the alarm
    signal once, then the apps will crash on the remote target. If I run the
    same apps manual with some printf in the signal handler, the apps will have
    no problems running.

  2. I have one developper using CodeWarrior 2.1, with the QNX SDK 2.11 ,
    and connecting to a QNX 2.11 PC without any problems. He is able to
    breakpoint into the is signal handler and CodeWarrior handles the alarm
    signals without any problems. If the same developer connects to a QNX RTP
    6.1 then we have some problems, and the apps crashes on the first signals
    coming in.

  3. At first I suspected library issues between the SDK 2.11 and the RTP 6.1,
    but I just received the new SDK 6.1 for windows that support QNX RTP 6.1.
    After installing the SDK, I am running into the same problems than 1. I
    suspect something was broken or repaired in pdebug on RTP 6.1 to cause this
    strange behavior.

Yes, there were changes made to pdebug to implement the gdb ‘handle signal’
functionality, and this may be where the problem lies.

Can you provide me with a simple test case? Something less than 100 lines?
In the meantime I will try an app with a SIGALRM handler, and see what happens.

Regards,
GP

any help or comments would be appreciated!!

Cheers!, Steph

3

Graeme Peterson <gp@qnx.com> wrote:

Stephane Grenier <> sgrenier@excalibur.com> > wrote:
Hi all!,

  1. We are running into some problem in debugging our signal handler with
    Codewarrior 2.1 and QNX RTP 6.1. The CodeWarrior SW will trap on the alarm
    signal once, then the apps will crash on the remote target. If I run the
    same apps manual with some printf in the signal handler, the apps will have
    no problems running.

  2. I have one developper using CodeWarrior 2.1, with the QNX SDK 2.11 ,
    and connecting to a QNX 2.11 PC without any problems. He is able to
    breakpoint into the is signal handler and CodeWarrior handles the alarm
    signals without any problems. If the same developer connects to a QNX RTP
    6.1 then we have some problems, and the apps crashes on the first signals
    coming in.

  3. At first I suspected library issues between the SDK 2.11 and the RTP 6.1,
    but I just received the new SDK 6.1 for windows that support QNX RTP 6.1.
    After installing the SDK, I am running into the same problems than 1. I
    suspect something was broken or repaired in pdebug on RTP 6.1 to cause this
    strange behavior.

Yes, there were changes made to pdebug to implement the gdb ‘handle signal’
functionality, and this may be where the problem lies.

Can you provide me with a simple test case? Something less than 100 lines?
In the meantime I will try an app with a SIGALRM handler, and see what happens.

Regards,
GP

I have verified that the following program works with gdb. Can you see if it
fails under CodeWarrior? Also, if you can export PDEBUG_DEBUG=1 before running
pdebug on the target, then please look for the following info:

…
…
ProtoVer X.X (mine says 0.1)
…
…
TargetHandlesig, passing signal 0x0
…
…

Here is the code.


#include <stdio.h>
#include <signal.h>

sig_atomic_t siggy = 0;

void myfunc(int signal_num)
{
siggy = signal_num;
}

int main(int argc, char **argv)
{
signal(SIGALRM, myfunc);

kill(getpid(), SIGALRM);
sleep(1);

printf(“Got signal %d %s\n”, siggy, siggy == SIGALRM ? “SIGALRM” : “NOT SIGALRM”);

return(0);
}

any help or comments would be appreciated!!

Cheers!, Steph

4

“Graeme Peterson” <gp@qnx.com> wrote in message
news:9rp7rh$qmc$1@inn.qnx.com…

Graeme Peterson <> gp@qnx.com> > wrote:
Stephane Grenier <> sgrenier@excalibur.com> > wrote:
Hi all!,

  1. We are running into some problem in debugging our signal handler
    with
    Codewarrior 2.1 and QNX RTP 6.1. The CodeWarrior SW will trap on the
    alarm
    signal once, then the apps will crash on the remote target. If I run
    the
    same apps manual with some printf in the signal handler, the apps will
    have
    no problems running.

  2. I have one developper using CodeWarrior 2.1, with the QNX SDK
    2.11 ,
    and connecting to a QNX 2.11 PC without any problems. He is able to
    breakpoint into the is signal handler and CodeWarrior handles the alarm
    signals without any problems. If the same developer connects to a QNX
    RTP
    6.1 then we have some problems, and the apps crashes on the first
    signals
    coming in.

  3. At first I suspected library issues between the SDK 2.11 and the RTP
    6.1,
    but I just received the new SDK 6.1 for windows that support QNX RTP
    6.1.
    After installing the SDK, I am running into the same problems than 1.
    I
    suspect something was broken or repaired in pdebug on RTP 6.1 to cause
    this
    strange behavior.

Yes, there were changes made to pdebug to implement the gdb ‘handle
signal’
functionality, and this may be where the problem lies.

Can you provide me with a simple test case? Something less than 100
lines?
In the meantime I will try an app with a SIGALRM handler, and see what
happens.

Regards,
GP

I have verified that the following program works with gdb. Can you see if
it
fails under CodeWarrior? Also, if you can export PDEBUG_DEBUG=1 before
running
pdebug on the target, then please look for the following info:

…
…
ProtoVer X.X (mine says 0.1)
…
…
TargetHandlesig, passing signal 0x0
…
…

Here is the code.


#include <stdio.h
#include <signal.h

sig_atomic_t siggy = 0;

void myfunc(int signal_num)
{
siggy = signal_num;
}

int main(int argc, char **argv)
{
signal(SIGALRM, myfunc);

kill(getpid(), SIGALRM);
sleep(1);

printf(“Got signal %d %s\n”, siggy, siggy == SIGALRM ? “SIGALRM” :
“NOT SIGALRM”);

return(0);
}

any help or comments would be appreciated!!

Cheers!, Steph

Hi Graeme!,

Tested your code and I having the same problems, my app will crash on the
first signal coming in. Also here is the rev number of pdebug

Build June 22, 2011
ProtoVer: 0.1

Cheers!, Steph

5

Stephane Grenier <sgrenier@excalibur.com> wrote:

<snip>

Hi, again.

The following code also stops before the printf() in CodeWarrior, but works
at the command line, and within GDB:

#include <stdio.h>
#include <signal.h>

int main(int argc, char **argv)
{
kill(getpid(), SIGCONT);
sleep(1);
printf(“We should see this!\n”);
return(0);
}

I will be taking this up with Metrowerks. Watch this space!

Regards,
GP

6

Graeme Peterson <gp@qnx.com> wrote:

Stephane Grenier <> sgrenier@excalibur.com> > wrote:

snip

Hi, again.

The following code also stops before the printf() in CodeWarrior, but works
at the command line, and within GDB:

#include <stdio.h
#include <signal.h

int main(int argc, char **argv)
{
kill(getpid(), SIGCONT);
sleep(1);
printf(“We should see this!\n”);
return(0);
}

I will be taking this up with Metrowerks. Watch this space!

Metrowerks has a fix for this being tested now. Please contact
support@metrowerks.com for availability of the fix.

Cheers.
GP

Regards,
GP