Re: LYNX-DEV More on my SPARC/Solaris 2.4/Lynx development version crashes

[Robert Bonomi]

[..  snip  ..]

+ > > program terminated by signal BUS (invalid address alignment)
+ > > Current function is LYLeakMalloc
+ > >   198           void *vp_malloc = (void *)malloc(st_bytes);
+ > > (dbx 1) where                                                         
+ > >   [1] t_delete(0x408858, 0xffffffff, 0xef655bf8, 0x408868, 0x408858, 
0xef655c84), at 0xef60be28
+ > >   [2] _malloc_unlocked(0x30, 0x0, 0x408858, 0x40, 0x408868, 0x408858), at 
0xef60b520
+ > >   [3] malloc(0x2c, 0x0, 0xffffffff, 0x0, 0x0, 0x42acc9), at 0xef60b368
+ > > =>[4] LYLeakMalloc(st_bytes = 44U, cp_File = 0x2729d8 
"../../Library/Implementation/HTString.c", ssi_Line = 82), line 198 in 
"LYLeaks.c"
+ > >   [5] HTSACopy(dest = 0x2e6f8c, src = 0x406380 
"http://homepage/home/lwv26/.parms/home.html";), line 82 in "HTString.c"
+ > >   [6] mainloop(), line 218 in "LYMainLoop.c"
+ > >   [7] main(argc = 2, argv = 0xefffe6c4), line 1694 in "LYMain.c"
+ > 
+ > 
+ > An "invalid address alignment" caused within the innards of the
+ > system's (C library's ?) implementation of malloc looks weird to me.
+ > Could also be that the Lynx code is writing to unallocated memory, but
+ > I have no indication that it does, or where it happens, and if it's
+ > somewhere in the innards of the style code I don't wanna look for it.
+ > But are you sure your system is sane?  Is there an alternative
+ > libmalloc or libgnumalloc or whatever you could try to link with?
+ 
+ I'm using, as far as I am aware, Sun's allocation code -there may be
+ other mallocs out there, but since my employer has a support contract
+ with Sun, we try to stick with the vendor as much as possible.  If
+ lynx is using it's own malloc, then I of course would be using it.

This is symptomatic of a 'trashed' malloc memory pool.  Look at the
manpage for 'malloc_debug',  link with the debugging version of 
malloc,  and turn on "full" checking at each call.  This is, in all
probability, one of those cases where the cause of the 'problem' is
a _long_ ways removed from where it manifests itself.  

It also appears to me that the *stack* is corrupted.
note that the traceback shows malloc called with SIX arguments!!
even tho the source-code clearly shows only one.  :)

Anybody got access to "Purify", or Centerline's "Codecenter", or 
similiar ??   <grin>
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;