[Xastir-dev] Another segmentation fault

[Jack Twilley]

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-----