Welcome to the Builder Academy

Question tba having "Heart Attacks" - signal 10, Bus error

More
03 Jul 2015 02:23 - 03 Jul 2015 20:13 #5379 by krell
the vnum for 90 appears to be the triggered timer and the only triggered timer before the MUD crashes.

"triggering timer for object 90"

Addendum

I've also logged the value of j at the time the call to timer_otrigger is made. It's definitely not NULL.

This is the melting ice cream trigger?
Last edit: 03 Jul 2015 20:13 by krell.

Please Log in or Create an account to join the conversation.

More
04 Jul 2015 20:55 - 04 Jul 2015 21:32 #5396 by krell
Here's a fully backtrace if it proves helpful. Some data snipped for security reasons. Hopefully it's enough to reveal where *j is being overwritten, IF *j is being overwritten, or at least give a hint to what's really going on.
Code:
GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-unknown-openbsd5.8"... Core was generated by `circle'. Program terminated with signal 10, Bus error. Loaded symbols for /<snipped>/bin/circle Reading symbols from /usr/lib/libc.so.79.0...done. Loaded symbols for /usr/lib/libc.so.79.0 Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so #0 0x000014ad23f51220 in timer_otrigger (obj=0x0) at dg_triggers.c:659 659 if (TRIGGER_CHECK(t, OTRIG_TIMER)) { (gdb) bt full #0 0x000014ad23f51220 in timer_otrigger (obj=0x0) at dg_triggers.c:659 t = (trig_data *) 0xdfdfdfdfdfdfdfdf #1 0x000014ad2402978f in point_update () at limits.c:459 i = (struct char_data *) 0x0 next_char = (struct char_data *) 0x0 j = (struct obj_data *) 0x14af593c6100 next_thing = (struct obj_data *) 0x14af593c6c00 jj = (struct obj_data *) 0x0 next_thing2 = (struct obj_data *) 0xfc415b17f634561 #2 0x000014ad2407f5f4 in heartbeat (heart_pulse=750) at comm.c:1006 mins_since_crashsave = 1 #3 0x000014ad2407f38a in game_loop (local_mother_desc=3) at comm.c:946 input_set = {fds_bits = {0 <repeats 32 times>}} output_set = {fds_bits = {16, 0 <repeats 31 times>}} exc_set = {fds_bits = {0 <repeats 32 times>}} null_set = {fds_bits = {0 <repeats 32 times>}} last_time = {tv_sec = 1435983269, tv_usec = 142379} opt_time = {tv_sec = 0, tv_usec = 100000} process_time = {tv_sec = 0, tv_usec = 18874} temp_time = {tv_sec = 0, tv_usec = 81126} before_sleep = {tv_sec = 1435983269, tv_usec = 61253} now = {tv_sec = 1435983269, tv_usec = 161260} timeout = {tv_sec = 0, tv_usec = 0} comm = "1\<snipped>\000�CR�\024\000\000\030\000\000\0000\000\000\000\020��\177\177\000\000P��\177\177\000\000Z�\230>�T���\177\177\000\000H\000\000\000\000\000\000\000\204Q\211R�\024\000\000�������\001\001\001\001\001\001\001\001�hFR�\024\000\000\005\000\000\000\000\000\000\000Z�\230>�T�\001\000\000\000\000\000\000\000�\217\210R�\024\000\000G\220\210R�\024\000\000\037eFR�\024\000\000�~\210R�\024\000\000\000\000\000\000\000\000\000\000�\217\210R�\024\000\000P��\177\177\000\000�~\210R�\024\000\000�eFR�\024\000\000P��\177\177\000\000"... d = (struct descriptor_data *) 0x0 next_d = (struct descriptor_data *) 0x0 missed_pulses = 0 maxdesc = 4 aliased = 0 #4 0x000014ad2407e39a in init_game (local_port=4000) at comm.c:534 No locals. #5 0x000014ad2407db27 in main (argc=3, argv=0x7f7ffffbea18) at comm.c:354 pos = 2 dir = 0x14afbfa977d0 "lib" (gdb)
Last edit: 04 Jul 2015 21:32 by krell.

Please Log in or Create an account to join the conversation.

More
04 Jul 2015 23:52 #5397 by thomas
I was certain I had replied to your previous post.

First off - have you tried to remove the object (or trigger) causing the crash? Does this stop the crash from occurring?
Is this the latest tba code?

Second - you can't trust the backtrace. Theres a stack error there. Note this:
Code:
#0 0x000014ad23f51220 in timer_otrigger (obj=0x0) at dg_triggers.c:659 t = (trig_data *) 0xdfdfdfdfdfdfdfdf #1 0x000014ad2402978f in point_update () at limits.c:459 ... j = (struct obj_data *) 0x14af593c6100
We know for a fact that timer_otrigger is passed 0x14af593c6100 as an argument but in the stacktrace this is overwritten with 0, and the value of t is also very suspect. Apparently the script running opurge self messes up the stack.

Please Log in or Create an account to join the conversation.

More
05 Jul 2015 00:23 - 05 Jul 2015 00:54 #5398 by krell
Yes, it is the latest tba codebase. No, I was about to try disabling the object and script I was busy trying to follow the code and make sense of it.

No, I realize that the bt might be suspect I'm just trying to provide any information that might prove useful. I've been trying to see why the value j points too isn't being picked up and am probably balder for the effort. :-)

I'll disable the object or script and report the changes, if any.

***

Addendum

Removed object 90 and its script from the world files for Zone 0. Uptime: 10 minutes and counting.

Addendum 2

I noticed in dg_triggers.c the obj argument of timer_otrigger() is declared as a pointer of struct obj_data, j is also declared as a pointer of struct obj_data in limits.c for point_update() , but the declaration of timer_otrigger() in dg_scripts.h has obj_data *obj as its argument.

Is this allowed in C or is declaring a a struct as a struct for each instance a member is made as a variable only a convention and not necessary? Just curious.
Last edit: 05 Jul 2015 00:54 by krell.

Please Log in or Create an account to join the conversation.

More
05 Jul 2015 09:33 #5401 by thomas
"obj_data *obj" means pointer to struct obj_data because there's a typedef in dg_scripts.h ( github.com/tbamud/tbamud/blob/master/src/dg_scripts.h#L197 )
Code:
typedef struct index_data index_data; typedef struct room_data room_data; typedef struct obj_data obj_data; typedef struct trig_data trig_data; typedef struct char_data char_data;

Please Log in or Create an account to join the conversation.

More
05 Jul 2015 13:28 #5402 by krell
Okay thanks, that clarifies things a bit for me.

Please Log in or Create an account to join the conversation.

Time to create page: 0.186 seconds