View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000643 | LDMud 3.3 | Runtime | public | 2009-05-28 08:44 | 2012-08-12 20:21 |
| Reporter | fufu | Assigned To | fufu | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | unable to reproduce | ||
| Platform | x86 | OS | Linux | OS Version | 2.6.25.20 |
| Product Version | 3.3.718 | ||||
| Summary | 0000643: ldmud loses reference counts to null_vector | ||||
| Description | I've tracked down the last crash of Wunderland to an attempt of freeing the empty array (null_vector in array.c). I've since logged the reference count of the null_vector and it seems to be decreasing at a rate of about 1000 per day. I have a log which shows that the reference count indeed drops below zero. (I've cheated and increased the reference count using gdb, to prevent the crash.) I'm not sure where to go from here - there's very little information to go on. I have not been able to produce wrong reference counts in a test mud at home. | ||||
| Additional Information | we're currently running SVN r2517 + the ipv6 bandaid patch of 0000616, with the wunderland settings. (notable: swapping enabled) As far as I can see, there are no new patches which would affect this reference count, but I may have missed something. Wunderland never does any garbage collections (which would correct the reference count and probably avoid the crash). To read out the null_vector refcount of the running mud, I'm using gdb /mud/bin/driver $(pidof driver) -ex 'print null_vector.ref' --batch | sed -nr 's/.* = //p' | ||||
| Tags | No tags attached. | ||||
|
|
Here's a backtrace of the crash: (gdb) where full #0 _free_vector (p=0x8117248) at array.c:306 i = 0 svp = <value optimized out> 0000001 0x0807e600 in free_array (a=0x8117248) at array.h:136 No locals. 0000002 0x0807f6de in free_svalue (v=0x898b580) at interpret.c:1348 needs_deserializing = <value optimized out> 0000003 0x080dd68c in handle_newly_destructed_objects () at simulate.c:2881 No locals. 0000004 0x080539ad in backend () at backend.c:403 buff = "who -k\0"... prevent_object_cleanup = false 0000005 0x080a6170 in main (argc=7, argv=0xbf9d8e34) at main.c:635 i = 5 set = {__val = {8192, 0 <repeats 31 times>}} rc = 0 (gdb) print &null_vector $9 = (vector_t *) 0x8117248 The freed vector, 0x8117248, is null_vector, whose reference count should never drop to 0. This is a SuSE distribution; glibc 2.8 (20080425) gcc (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (I can't rule out the possibility that the compiler has miscompiled something) |
|
|
This behavious has disappeared after moving to a new machine. Possible causes include hardware and compiler bugs. --> closing. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-05-28 08:44 | fufu | New Issue | |
| 2009-05-28 09:05 | fufu | Note Added: 0001172 | |
| 2009-06-01 05:38 | zesstra | Project | LDMud => LDMud 3.3 |
| 2012-08-12 20:21 | fufu | Note Added: 0002149 | |
| 2012-08-12 20:21 | fufu | Status | new => closed |
| 2012-08-12 20:21 | fufu | Assigned To | => fufu |
| 2012-08-12 20:21 | fufu | Resolution | open => unable to reproduce |
