[Xastir-dev] Another segmentation fault
Jack Twilley
jmt at twilley.org
Tue Dec 16 14:14:13 EST 2003
WARNING: Unsanitized content follows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>>>>> "Curt" == Curt Mills <Curt> writes:
[... backtrace and packets elided ...]
Jack> That section of alert.c deals with cancelled alerts. The first
Jack> portion of the conditional of the if statement surrounding line
Jack> 645 checks to see if alert->alert_level is equal to 'C'. When I
Jack> looked at the variable alert->alert_level in the debugger, it
Jack> was equal to -48, which is a sign that the memory allocated to
Jack> alert was freed.
Curt> If that is true, then the structure passed in to the routine was
Curt> freed earlier, before alert_match() was called.
That was my suspicion as well.
Curt> There are no free() calls in that file. There's one realloc()
Curt> call, and no malloc() calls. To "free" a record, we clear out
Curt> the title in alert_active() by write a '\0' to alert->title[0].
Ah. That was not the case here.
Curt> So... It appears to not be a free() problem, but perhaps pointer
Curt> mismanagement, resulting in a pointer gone awry?
Or a list management problem, like the last one.
Curt> Can you look to see if the rest of it looks at all like an alert
Curt> record?
The rest of it looks like free()'d memory.
Jack> Curt, if you need me to do more here, just ask. I figure that
Jack> by this part of the message, you've already identified exactly
Jack> what's wrong. :-) However, if there's more research to be done
Jack> to give you more data, just ask.
Curt> It _would_ have to be in the alert code! That stuff has been
Curt> severely hacked up over the years and needs a total rewrite. I
Curt> cringe every time I think about having to go back into that part
Curt> of the code. That code likes to fall over if you change
Curt> something really insignificant in it.
The alert code scares me too. I was thinking that it might be best to
write up a specification for what the code is supposed to do, and then
recreate the code from scratch.
Curt> The new alerts coming in activated code that tried to look for a
Curt> match in the list. I doubt the packets listed will help in this
Curt> matter, as it's likely a list management problem. It'll
Curt> probably take a bunch of work to figure out where the problem
Curt> lies.
Well, I got another one last night.
Here's the last two lines from the TNC log:
KE6UKR-3>WIDE>WIDE3*>BEACON:Located east of Columbia on Telegraph Hill @ 3738 ft.
KF6HJO>WIDE2*>APS221:}HNXNPW>APRS,TCPIP,KF6HJO*::NWS_ADVIS:161200z,DENSE_FOG,CAZ89>92 {G6TAB
The backtrace is identical. Here's what the alert record looks like:
(gdb) output *alert
{top_boundary = -1.993854408381186e+81,
left_boundary = -1.993854408381186e+81,
bottom_boundary = -1.993854408381186e+81,
right_boundary = -1.993854408381186e+81, expiration = -791621424,
activity = 'Ð' <repeats 21 times>, alert_tag = 'Ð' <repeats 21 times>,
title = "\0", 'Ð' <repeats 32 times>, alert_level = -48 'Ð',
from = "ÐÐÐÐÐÐÐÐÐÐ", to = "ÐÐÐÐÐÐÐÐÐÐ", flags = 'Ð' <repeats 16 times>,
filename = 'Ð' <repeats 64 times>, index = -791621424, seq = "ÐÐÐÐÐÐÐÐÐÐ",
issue_date_time = "ÐÐÐÐÐÐÐÐÐÐ", desc0 = 'Ð' <repeats 68 times>,
desc1 = 'Ð' <repeats 68 times>, desc2 = 'Ð' <repeats 68 times>,
desc3 = 'Ð' <repeats 68 times>}
So alert was pointing to free()'d memory in this case. I think you're
right when you're talking about it being a list thing.
Jack.
- --
Jack Twilley
jmt at twilley dot org
http colon slash slash www dot twilley dot org slash tilde jmt slash
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQE/31mLGPFSfAB/ezgRAgVLAJ912CROGDzS6DsBStTUPtUgNyoUIACg2E6I
DN9i5u6LMPPrO27tlKdMu+s=
=rh37
-----END PGP SIGNATURE-----
More information about the Xastir-dev
mailing list