Re: Crtl-C -> panic

[David Bateman]

According to John W. Eaton <address@hidden> (on 06/17/04):
> 
> To send a signal to a process from gdb, you can do
> 
>   (gdb) signal SIGINT
> 
> then you can step through the process.

(gdb) handle SIGINT stop print pass

should stop on a SIGINT but still pass it to the process after a continue.
So stepping through the code should then be possible also.

> The problem seems to be also related to building with shared
> libraries, since I don't see the problem with a version that is
> compiled and linked statically.
> 
> I tried commenting out the code that installs the new types and
> operators for those types, but the problem remains.

The problem predates the int/uint types by quite a bit. I've noticed this
problem for at least a month or so, but thought it was to do with the
changes to the core-dump code and was a misconfiguration on my part.
Unfortunately not, so I filed a bug report hoping someone (you?) had a
simple fix :-)

> Even though I can send SIGINT to Octave from gdb, I'm not sure that
> will point directly to the location of the actual error.  Perhaps the
> best thing to do is step backward in time with CVS and try to pinpoint
> the changes that cause the problem.

As I said I can't step through the code at all, it seems that the SIGINT
is received while in libc and gdb won't let me step out. A bit odd, and
probably also a problem on my side. I'll try and figure out why I can't
step through the code.

Look through src/ChangeLog form March, April and May, I can't see anything
directly related to this issue, so I wonder if the problem also exists
on 2.1.57 versions dynamically linked. So my first step will be to
check 2.1.57 built in exactly the same manner.

Unfortunately, complex cvs manipulations like you suggest above are a
real pain behind a corporate firewall. It seems I've taken responsiblity
for this issue, so I'll see what I can find out...


> | I also then tried to build octave-forge with this CVS and got no where,
> | firstly the configure script failed to correctly determine some option
> | (due to mkoctfile failing) and the build failed on the compile of the
> | first oct-file. This seems to have something to do with the introduction
> | of the int/uint types....
> 
> I expect some trouble, and will try to build octave-forge so I can see
> what changes will be needed (either to Octave, or to other code) when
> I get some time.

I understand that introducing new code always involves some pain. I
was just pointing out that an issue exists with using mkoctfile after
inclusion of int/uint stuff. I presume it is just some missing header
or template files in the install as octave itself built fine. However,
I didn't investigate further on the cause of the issue at this point..

Cheers
D.

-- 
David Bateman                                address@hidden
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary