[Xastir-dev] Another segmentation fault

[Curt Mills, WE7U]

On Mon, 15 Dec 2003, Jack Twilley wrote:

> Here's the backtrace:
>
> (gdb) bt
> #0  0x28ecb40c in strcmp () from /lib/libc.so.5
> #1  0x0804f9f5 in alert_match (alert=3D0x8927474, match_level=3DALERT_FROM)
>     at alert.c:645
> #2  0x0804fc14 in alert_active (alert=3D0x8927474, match_level=3DALERT_FROM)
>     at alert.c:787
> #3  0x0804fea2 in alert_on_screen () at alert.c:936
> #4  0x080a1bdf in UpdateTime (clientData=3D0x8586400, id217025404)
>     at main.c:9332
> #5  0x28398b6e in DoOtherSources () from /usr/X11R6/lib/libXt.so.6
> #6  0x28398e2e in XtAppNextEvent () from /usr/X11R6/lib/libXt.so.6
> #7  0x2838d98c in XtAppMainLoop () from /usr/X11R6/lib/libXt.so.6
> #8  0x080b9a7a in main (argc=3D2, argv=3D0xbfbfeb94) at main.c:25598
> #9  0x0804ed82 in _start ()
>
> The last two lines of my TNC log were:
>
> KF6HJO*>WIDE2>APS221:}HNXNPW>APRS,TCPIP,KF6HJO*:;HNXN0629z*161200z3613.20N\=
> 11946.20W{Center DENSE_FOG {G6TAA
> KF6HJO*>WIDE2>APS221:}HNXNPW>APRS,TCPIP,KF6HJO*::NWS_ADVIS:161200z,DENSE_FO=
> G,CAZ89>92 {G6TAB
>
> That section of alert.c deals with cancelled alerts.  The first
> portion of the conditional of the if statement surrounding line 645
> checks to see if alert->alert_level is equal to 'C'.  When I looked at
> the variable alert->alert_level in the debugger, it was equal to -48,
> which is a sign that the memory allocated to alert was freed.

If that is true, then the structure passed in to the routine was
freed earlier, before alert_match() was called.

There are no free() calls in that file.  There's one realloc() call,
and no malloc() calls.  To "free" a record, we clear out the title
in alert_active() by write a '\0' to alert->title[0].

So... It appears to not be a free() problem, but perhaps pointer
mismanagement, resulting in a pointer gone awry?

Can you look to see if the rest of it looks at all like an alert
record?


> Curt, if you need me to do more here, just ask.  I figure that by this
> part of the message, you've already identified exactly what's wrong. :-)
> However, if there's more research to be done to give you more data,
> just ask.

It _would_ have to be in the alert code!  That stuff has been
severely hacked up over the years and needs a total rewrite.  I
cringe every time I think about having to go back into that part of
the code.  That code likes to fall over if you change something
really insignificant in it.

The new alerts coming in activated code that tried to look for a
match in the list.  I doubt the packets listed will help in this
matter, as it's likely a list management problem.  It'll probably
take a bunch of work to figure out where the problem lies.

-- 
Curt Mills, WE7U                    hacker_NO_SPAM_ at tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto:    A tax on people who are bad at math!"
"Windows:  Microsoft's tax on computer illiterates!" -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"