Server Help Forum Index Server Help
Community forums for Subgame, ASSS, and bots
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   StatisticsStatistics   RegisterRegister 
 ProfileProfile   Login to check your private messagesLogin to check your private messages   LoginLogin (SSL) 

Server Help | ASSS Wiki (0) | Shanky.com
?shutdown segfault

 
Post new topic   Reply to topic Printable version
 View previous topic  Config files Post :: Post Dl  View next topic  
Author Message
Snidjer
Newbie


Age:42
Gender:Gender:Male
Joined: Jun 22 2003
Posts: 19
Location: Netherlands
Offline
PostPosted: Mon Jun 23, 2003 5:48 pm    Post subject: ?shutdown segfault Reply to topic Reply with quote
Well, it *does* segfault when I'm running GDB, but unfortunately GDB isn't liking backtracing threads. But the culprit line is net.c:747.

Quote:

0x4016248d in RecvThread (dummy=0x40173120) at net.c:747
747 len = enc->Decrypt(p, buf->d.raw, len);


Unfortunately, you all haven't distributed the encryption code (dunno why...) so I'm not sure what there is to do about this.

Hm. Actually I've just been working on debugging. If I try to output that expression, I get

Quote:

(gdb) output len = enc->Decrypt(p, buf->d.raw, len)
Cannot access memory at address 0x40313518


No clue what you guys are doing at shutdown because I've not looked at the code a whole lot, but perhaps this gives you some ideas.

Kind regards,

Devon H. O'Dell
sitetronics.com

EDIT:

Is it possible that you unload modules before this point? If so, the functions can't be loaded anymore. I'm also unable to access the memory at buf->d.raw (its 0x20 on my system). Although p still exists.

Quote:
(gdb) print p
$1 = (Player *) 0x8068f58


I don't know what len is supposed to be.

Quote:
(gdb) print len
$2 = 5000


Trying to pass the buffer into ProcessBuffer segfaults of course. I'll post more info as I know it.

(releasing chat)
Quote:
I <cmdman> {0} [Snidjer] Command (arena) 'shutdown'

Breakpoint 1, ReleaseInterface (iface=0x14) at module.c:530
530 {
(gdb) bt
#0 ReleaseInterface (iface=0x14) at module.c:530
#1 0x0804a6ef in main (argc=1075188996, argv=0x40161680) at main.c:279
#2 0x4016ee12 in _fini () from /home/dodell/asss-0.9.13/bin/core.so
Cannot access memory at address 0x46692016


(killing connections)
Quote:
Breakpoint 1, ReleaseInterface (iface=0x0) at module.c:530
530 {
(gdb) bt
#0 ReleaseInterface (iface=0x0) at module.c:530
#1 0x401633c1 in KillConnection (p=0x0) at net.c:1345
#2 0x6a64696e in ?? ()
Cannot access memory at address 0x53000003


(releasing persist)
Quote:
#0 ReleaseInterface (iface=0x14) at module.c:530
#1 0x0804a750 in main (argc=1075188996, argv=0x40161680) at main.c:292
#2 0x4016ee12 in _fini () from /home/dodell/asss-0.9.13/bin/core.so
Cannot access memory at address 0x46692016


here's where it gets interesting (after releasing the ml loop)

Quote:
(gdb) step
main (argc=1075188996, argv=0x40161680) at main.c:299
299 mm->frommain.DoStage(MM_PREUNLOAD);
(gdb) step
DoStage (stage=1075188996) at module.c:348
348 {
(gdb) step
350 pthread_mutex_lock(&modmtx);
(gdb) step
348 {
(gdb) step
DoStage (stage=Cannot access memory at address 0x22
) at module.c:350
350 pthread_mutex_lock(&modmtx);
...
MM_logman (action=Cannot access memory at address 0x12
) at logman.c:62
...


At this point, I believe these modules have been unloaded, but I'm not certain.

Now we get this for the first time from the logman

Quote:
MM_logman (action=Cannot access memory at address 0x12
) at logman.c:63
63 mm->ReleaseInterface(aman); aman = NULL;
(gdb) next

Breakpoint 1, ReleaseInterface (iface=Cannot access memory at address 0x12
) at module.c:530
530 {
(gdb) next
532 if (!iface) return;
(gdb) next
533 assert(head->magic == MODMAN_MAGIC);
(gdb) next
534 head->refcount--;
(gdb) next
535 }
(gdb) next
MM_logman (action=Cannot access memory at address 0x12
) at logman.c:64
64 }
(gdb) next
74 return MM_FAIL;
(gdb) next
75 }
(gdb) bt
#0 MM_logman (action=Cannot access memory at address 0x12
) at logman.c:75
#1 0x08052bc0 in ?? ()
Cannot access memory at address 0x2


Now we're unloading all modules...

Quote:
351 for (l = LLGetHead(&mods); l; l = l->next)
(gdb) next
352 ((ModuleData*)l->data)->mm(stage, &mmint, ALLARENAS);
...
MM_config (action=Cannot access memory at address 0x12
) at config.c:534
534 }
(gdb) next
561 return MM_FAIL;
...
MM_arenaman (action=Cannot access memory at address 0x12
) at arenaman.c:668
...
713 mm->ReleaseInterface(persist);
(gdb) next
...
MM_arenaman (action=Cannot access memory at address 0x12
) at arenaman.c:714
714 }
(gdb) next
745 return MM_FAIL;
...
MM_mapdata (action=Cannot access memory at address 0x12
) at mapdata.c:89
...
106 else if (action == MM_UNLOAD)
(gdb) next
121 return MM_FAIL;


I think you get the point. Looks like all modules unload fine (except for that they all return MM_FAIL? The only one that doesn't return this is one I've compiled for Mr. Twit, a racing module he wrote. It returns MM_OK)

Now it's removing a ton of commands, but I keep getting stuff like "HashGetAppend (h=0x1824748b, s=0xb60f1675 <Address 0xb60f1675 out of bounds>, res=0xe8830142) at util.c:639"

It seems to me that this would be because the modules are unloaded (so it doesn't know what to be removing from the hash table?), but I dunno how your API works.

So anyway, despite that, the call to UnloadModuleByPtr returns MM_OK.

Fuck. I've managed to get myself into net.c already. And now, what's even weirder, I get

Quote:
789 pd->Lock();
(gdb)
[Switching to Thread 3076 (LWP 17855)]
SendThread (dummy=0x0) at net.c:1153
1153 gtc = GTC();
(gdb)

Cannot find thread 6151: no thread to satisfy query


So in any case, it seems to be hanging around in the player.c code. I'm not sure that the weird privatequit variable is ever getting set.

Anyway, it's midnight here and I'm probably not doing more than bugging you with my debugging :-\ Sorry.

EDIT: Don't know why the [ code ] fucks up in first posts in a thread, changed to [ quote ]'s -MGB
Back to top
View users profile Send private message Add User to Ignore List Visit posters website
Grelminar
Creator of Asss


Joined: Feb 26 2003
Posts: 378
Offline
PostPosted: Tue Jun 24, 2003 12:59 am    Post subject: Reply to topic Reply with quote
I'm pretty sure this issue is fixed in the latest cvs code. You were basically right: it was trying to call stuff in certain modules (like the encryption modules) after they were unloaded. I'm not sure about the other strange stuff you saw, but I'll assume they were caused by the same problem. If not, I'll take another look.
Back to top
View users profile Send private message Add User to Ignore List Send email Visit posters website
Smong
Server Help Squatter


Joined: 1043048991
Posts: 0x91E
Offline
PostPosted: Tue Jun 24, 2003 4:10 pm    Post subject: Re: ?shutdown segfault Reply to topic Reply with quote
Snidjer wrote:
I think you get the point. Looks like all modules unload fine (except for that they all return MM_FAIL? The only one that doesn't return this is one I've compiled for Mr. Twit, a racing module he wrote. It returns MM_OK)

That's probably because I handle all actions in a switch() and Grel just uses ifelse on what he needs.
Back to top
View users profile Send private message Add User to Ignore List Visit posters website MSN Messenger
Display posts from previous:   
Post new topic   Reply to topic    Server Help Forum Index -> ASSS Questions All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
View online users | View Statistics | View Ignored List


Software by php BB © php BB Group
Server Load: 33 page(s) served in previous 5 minutes.

phpBB Created this page in 0.549853 seconds : 28 queries executed (94.6%): GZIP compression disabled