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

thomas wrote: Actually, t->next also could point to garbage - if the object has been free'd, so would the triggers be.

Which function is responsible for freeing these particular pointers in timer_otrigger()?

Compiled and ran the code with your modifications, I left the return statement out at the end. I figure that's probably okay due to it being a void function and your saying it's okay.

None of the timer scripts caused a crash. I created an object with multiple timers that all ran seemingly concurrently. Again, no crashes.

The only error that appeared in syslog was
"SYSERR: Freeing null pointer dg_olc.c:417" during the OLC session to create my test objects and scripts. Again, I assume that's okay, if not great, as free is acting on a null pointer and should, by default, do nothing?

Addendum:

I just realized I was being stupid only in the way a sleep deprived brain could be. To correct this I put this entry in the modifications:
log("SYSERR: data in obj not equal to data in tmp. obj=%p tmp=%p", obj, tmp);

This shows up in the syslog by the way.

SYSERR: data in obj not equal to data in tmp. obj=0x0 tmp = 0xaf0..... So obj is null'd? I've heard this before. It's also when running self purging timers.

Yes, this is exactly what I figured was the problem. I suggest simply removing the log line, now we know it was the actual bug.

If something is free'd in script_driver() we don't want to do more to it.

@someone who actually handles the code these days: you should put a null check in that function.

Thanks thomas. I'll keep the modifications in trigger_otimer() as you recommend as a workaround. I am curious as to why you think script_driver() is setting pointer obj to NULL when it seems obj is NULL before it's passed to script_driver()?

Because the problem happens the second time in the loop.

Here's the scenario:
Two triggers on one object.
First trigger purges the object, and now the obj pointer is pointing at NULL.
Second loop through, and we're passing garbage to the script_driver.
This thrashes the stack and clouds our backtrace.

This is in short what the logging is telling us.