03 Dec, 2008, The_Fury wrote in the 1st comment:
Votes: 0
I have no idea on this one, can anyone give me some clues as to what when wrong?

#0  0xb7fcc7f2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0xb7e4cd20 in raise () from /lib/libc.so.6
#2 0xb7e4e631 in abort () from /lib/libc.so.6
#3 0xb7e84e6b in __libc_message () from /lib/libc.so.6
#4 0xb7e8cb16 in _int_free () from /lib/libc.so.6
#5 0xb7e90070 in free () from /lib/libc.so.6
#6 0x08062123 in update_imchistory (channel=0x9ad6bc8,
message=0xbfee3e20 "~R[~Yinews~R] ~CCNN@MegaBot: ~cThai flights resume after week of protests (http://edition.cnn.com/2008/WORLD/asiapc...)") at imc.c:1780
#7 0x08062552 in imc_display_channel (c=0x9ad6bc8,
from=0x9b1d670 "CNN@MegaBot",
txt=0xbfee5650 "Thai flights resume after week of protests (http://edition.cnn.com/2008/WORLD/asiapc...)",
emote=0) at imc.c:1855
#8 0x0806271d in imc_recv_broadcast (q=0x9b1d668,
packet=0x9acacc7 "echo=0 text=\"Thai flights resume after week of protests (http://edition.cnn.com/2008/WORLD/asiapc...)\" emote=0 channel=Server02:inews ") at imc.c:1898
#9 0x08065c20 in imc_parse_packet (
packet=0x9acacc7 "echo=0 text=\"Thai flights resume after week of protests (http://edition.cnn.com/2008/WORLD/asiapc...)\" emote=0 channel=Server02:inews ") at imc.c:2973
—Type <return> to continue, or q <return> to quit—
#10 0x08066b6d in imc_loop () at imc.c:3386
#11 0x080e2ddd in game_loop () at comm.c:552
#12 0x080e23f5 in main (argc=2, argv=0xbfee7994) at comm.c:215
(gdb)
03 Dec, 2008, Sharmair wrote in the 2nd comment:
Votes: 0
Not really much here to go by. The problem has to do with free being called from your code in
frame 6, so I would look there to see what the line actually looks like. I would check and make
sure you are not mixing str_dup/DISPOSE with STRALLOC/STRFREE as that is probably the thing
that causes this type of crash most often in SMAUG derivatives (which I am assuming you are using).
I took a look in an i3.c I have here and the function that probably does the same thing as your
function that is crashing uses I3STRALLOC/I3STRFREE that are resolved to STRALLOC/STRFREE
in i3cfg.h. I would not be surprised if imc did something like that too.
03 Dec, 2008, The_Fury wrote in the 3rd comment:
Votes: 0
Here is the surrounding block: <— indicates the line from frame 6


I dont know whats throwing out the page rendering either. Sorry about that.
if( x == MAX_IMCHISTORY - 1 )
{
int y;

for( y = 1; y < MAX_IMCHISTORY; y++ )
{
int z = y - 1;

if( channel->history[z] != NULL )
{
IMCSTRFREE( channel->history[z] ); <—
channel->history[z] = IMCSTRALLOC( channel->history[y] );
}
}

local = localtime( &imc_time );
snprintf( buf, LGST, "~R[%-2.2d/%-2.2d %-2.2d:%-2.2d] ~G%s",
local->tm_mon + 1, local->tm_mday, local->tm_hour, local->tm_min, msg );
IMCSTRFREE( channel->history[x] );
channel->history[x] = IMCSTRALLOC( buf );

if( IMCIS_SET( channel->flags, IMCCHAN_LOG ) )
{
FILE *fp;
snprintf( buf, LGST, "%s%s.log", IMC_DIR, channel->local_name );
if( !( fp = fopen( buf, "a" ) ) )
{
perror( buf );
imcbug( "Could not open file %s!", buf );
}
else
{
fprintf( fp, "%s\n", imc_strip_colors( channel->history[x] ) );
IMCFCLOSE( fp );
}
}
}
03 Dec, 2008, Cratylus wrote in the 4th comment:
Votes: 0
Sharmair wrote:
Quote
I would check and make sure you are not mixing str_dup/DISPOSE with STRALLOC/STRFREE


Wow nice guess.

Was that really just a guess or did you see something in the bt that cued you?

Also, Fury, what's the signal being thrown? I guess a segfault but I'd like to know for sure.
You might want to include the entirety of the file, since IMCSTRFREE() seems to be the
problem and I don't see that its definition is in your code quote.

-Crat
http://lpmuds.net
03 Dec, 2008, Lobotomy wrote in the 5th comment:
Votes: 0
You know, deallocating then reallocating the string every single step really isn't the best way to go about shifting the members of an array of string pointers:

for( y = 1; y < MAX_IMCHISTORY; y++ )
{
int z = y - 1;

if( channel->history[z] != NULL )
{
IMCSTRFREE( channel->history[z] ); <—
channel->history[z] = IMCSTRALLOC( channel->history[y] );
}
}

The benefit of them being pointers is that you can assign the pointer value of the one ahead to the one previous and achieve the same effect. Fixing that section might not necessarily fix your problem (I've not used IMC so I don't know what it all entails exactly), but at the least it could speed it up a little.

At least, that's the thing that stands out to me the most at the moment. If I didn't have to rush to work right now I'd take a little more time to look the code over further, but yeah…

Good luck though, The_Fury! :smile:
03 Dec, 2008, The_Fury wrote in the 6th comment:
Votes: 0
Thanks Lobotomy, i need all the help i can get, Imc code is not something that i really understand.

@Crat Program terminated with signal 6, Aborted.

#define IMCCREATE(result, type, number)                           \
do \
{ \
if (!((result) = (type *) calloc ((number), sizeof(type)))) \
{ \
imclog( "Malloc failure @ %s:%d\n", __FILE__, __LINE__ ); \
abort(); \
} \
} while(0)

#define IMCRECREATE(result, type, number) \
do \
{ \
if(!((result) = (type *)realloc((result), sizeof(type) * (number)))) \
{ \
imclog( "Realloc failure @ %s:%d\n", __FILE__, __LINE__ ); \
abort(); \
} \
} while(0)

#define IMCDISPOSE(point) \
do \
{ \
if((point)) \
{ \
free((point)); \
(point) = NULL; \
} \
} while(0)

#define IMCSTRALLOC strdup
#define IMCSTRFREE IMCDISPOSE


Thats the macro for IMCSTRFREE, I should also mention that this is the latest imc code release thats available on this site. EDIT: added in all the memory macros just to be sure to be sure.
03 Dec, 2008, David Haley wrote in the 7th comment:
Votes: 0
Cratylus said:
Was that really just a guess or did you see something in the bt that cued you?

Seeing problems in free very strongly suggests that something is being freed twice. (The other strong possibility is that something is being freed that wasn't allocated to begin with.) That also strongly suggests that hashed string functions are being mixed with non-hashed strings.
03 Dec, 2008, Scandum wrote in the 8th comment:
Votes: 0
Looks to me like you need to use MAX_IMCHISTORY -1 to avoid going out of bounds.

for( y = 1; y < MAX_IMCHISTORY - 1 ; y++ )
{
int z = y - 1;

if( channel->history[z] != NULL )
{
IMCSTRFREE( channel->history[z] );
channel->history[z] = IMCSTRALLOC( channel->history[y] );
}
}
03 Dec, 2008, Lobotomy wrote in the 9th comment:
Votes: 0
I suppose seeing the IMC code looking like this just reinforces my prior thought that I'll need to write my own client (if I get around to dealing with IMC, anyways). Anyhow, the thing I just wanted to throw in from before I left was an example of how the particular loop that's shifting the array would look in regards to what I was talking about:

int y = 1;
if( channel->history[0] )
IMCSTRFREE( channel->history[0] );
for( ; y < MAX_IMCHISTORY; y++ )
channel->history[y-1] = channel->history[y];


Scandum said:
Looks to me like you need to use MAX_IMCHISTORY -1 to avoid going out of bounds.

Unless they're defining the history array as MAX_IMCHISTORY - 1, the current setup is fine since they're using y < (max) for the for loop. Once y is equal to the max, the for loop will kick, thus y is always in bounds.
03 Dec, 2008, David Haley wrote in the 10th comment:
Votes: 0
Could we maybe edit the gdb output and shorten the very long strings so that the thread becomes readable again?
03 Dec, 2008, Scandum wrote in the 11th comment:
Votes: 0
Lobotomy said:
Unless they're defining the history array as MAX_IMCHISTORY - 1, the current setup is fine since they're using y < (max) for the for loop. Once y is equal to the max, the for loop will kick, thus y is always in bounds.

You're right, it's quite unlikely.

Another guess would be that channel->history[y] is NULL in the last call of the loop when y == MAX_IMCHISTORY - 1

if ( x == MAX_IMCHISTORY) and using x-1 would fix this.
03 Dec, 2008, The_Fury wrote in the 12th comment:
Votes: 0
Sorry David i am unable to edit my original post.

1780                   IMCSTRFREE( channel->history[z] );
(gdb) list
1775 {
1776 int z = y - 1;
1777
1778 if( channel->history[z] != NULL )
1779 {
1780 IMCSTRFREE( channel->history[z] );
1781 channel->history[z] = IMCSTRALLOC( channel->history[y] );
1782 }
1783 }
1784
(gdb) print z
$1 = 0
(gdb) Quit
(gdb) print y
$2 = 1
(gdb)


Here is a print of z and y
04 Dec, 2008, Lobotomy wrote in the 13th comment:
Votes: 0
Is that gdb output from the time of a crash, perhaps (you didn't say, so I'm guessing)? If so, maybe you should try commenting out that section of the code and replacing it with the above code example I posted and see if it still crashes then? :thinking:
04 Dec, 2008, The_Fury wrote in the 14th comment:
Votes: 0
Well the trouble is, it has not crashed since, it seems to be a one off thing that has some very specific requirements to make it happen. channel->history[z] and channel->history[y] both contain valid data, its one of these peculiar bugs that is beyond my ability to decipher.
10 Dec, 2008, ghasatta wrote in the 15th comment:
Votes: 0
Quote
Well the trouble is, it has not crashed since, it seems to be a one off thing that has some very specific requirements to make it happen. channel->history[z] and channel->history[y] both contain valid data, its one of these peculiar bugs that is beyond my ability not worth my time to decipher.


FTFY ;)

If it's that obscure then I would suggest you not worry too much about it. You probably have plenty of other things to work on, no sense in keeping those enhancements / cool new stuff on the back burner while you track down an obscure bug. imho.
10 Dec, 2008, The_Fury wrote in the 16th comment:
Votes: 0
Yeah i agree Ghasatta, its the 10th today and it has not happened again, but its always nice to know that you can fix these sorts of things.
0.0/16