Descriptive Problem Summary:
Backtrace for BYOND 475.1080 on Linux:
Generated at Sun Sep 5 16:56:02 2010
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a668]
libbyond.so 0x2e23b0, 0x2e23be
[0xf57fe000, 0xf57fe40c], [0xf57fe000, 0xf57fe40c]
libbyond.so 0x2e23b0, 0x2e23be
libbyond.so 0x27cba0, 0x27cbc7
libbyond.so 0x2060b0, 0x20612e
libbyond.so [0xb7466000, 0x0], 0x234679
libbyond.so [0xb7466000, 0x0], 0x234867
libbyond.so 0x23bfa0, 0x23c07a
libbyond.so [0xb7466000, 0x0], 0x25ca46
libbyond.so [0xb7466000, 0x0], 0x246969
libbyond.so 0x25a970, 0x25aa80
libbyond.so 0x25aad0, 0x25ab7d
libbyond.so [0xb7466000, 0x0], 0x25afa6
libbyond.so [0xb7466000, 0x0], 0x24c852
libbyond.so 0x25a970, 0x25aa80
libbyond.so 0x25aad0, 0x25ab7d
libbyond.so [0xb7466000, 0x0], 0x25bf8d
libbyond.so [0xb7466000, 0x0], 0x24720a
libbyond.so [0xb7466000, 0x0], 0x25955b
libbyond.so 0x2598e0, 0x259a05
libbyond.so [0xb7466000, 0x0], 0x223df4
libbyond.so 0x2d5370, 0x2d54cc
libbyond.so 0x2a9280, 0x2a94b6
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a163]
libc.so.6 0x16af0, 0x16bd6 (__libc_start_main)
DreamDaemon [0x8048000, 0x8049af8], [0x8048000, 0x8049c31]
To help the BYOND developers debug this, please send the above trace as part
of a very detailed bug report: http://www.byond.com/members/?command=view_tracker&tracker=1
what caused it:
BUG: Crashing due to an illegal operation!
Sun Sep 5 16:56:02 2010
proc name: New (/obj/Effects/Smoke/New)
usr: null
src: Smoke (/obj/Effects/Smoke)
call stack:
Smoke (/obj/Effects/Smoke): New(The Great Forge (197,90,1) (/turf/Special/ForgeDump))
Chimney (/obj/Chimney): Smoking()
Chimney (/obj/Chimney): Smoking()
I'm not sure why it caused it to crash, since the chimey constantly smokes, all the time, and the server was up for about a day and a half
Numbered Steps to Reproduce Problem:
1) Host Harvest Moon: Trinity Ranch on ubuntu 10.04, and wait ( http://www.byond.com/games/WildBlood/HarvestMoonTrinityRanch )
Expected Results: No crashes
Actual Results: Crashes
Does the problem occur:
Every time? Or how often? Since the update to byond 475, its only happened once
In other games? unsure
In other user accounts? unsure
On other computers? unsure
When does the problem NOT occur? 99.99999999999999% of the time the chimmy smoking does not cause it to crash, but i guess it only takes one :/
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.) untested
Workarounds: none?
ill keep you posted if I continue to get crash messages
Note: The rsc file has not been tampered with whatsoever.
ID:101499
 Sep 5 2010, 1:30 pm
|
|||||||||||||
Resolved
| |||||||||||||
How do I make DreamDaemon do a core dump under linux?
| |
Run it with: DreamDaemon game port -core
| |
Also, make sure your machine is setup to dump core by doing: ulimit -c unlimited
| |
It finally crashed again. Here is the core file: http://cinnom.net/files/core
This may be a separate issue, but the DreamDaemon process has also been jumping to 100% CPU usage since updating. It instantly jumps up and stays there after running for a few hours or so. I've been using a program called cpulimit to limit the DreamDaemon process to 20% CPU. The high CPU usage seems to have no negative effect on the game (unless it's causing the crash) and limiting it also has no negative effect. | |
I'll check out the core, thanks.
Which version did you update from? | |
He was using byond version 467.1069 before updating to 475.
| |
Unfortunately I was not able to get much out of the core. I could provide an alternate binary that can likely give me better info.
That said, the best way to diagnose both problems would be to have access to your machine. Any chance you could create an account for me and put the game files in there to host? I could then upload a debug binary that we could run and that would also allow me to check the state of the game at runtime when it is using so much cpu (which concerns me more than the crash). Alternatively, if you give me the game files I could host it on one of our machines here and see if the issue occurs. That is not as reliable since it may be crashing due to a platform-specific setup, but it wouldn't hurt much to test. | |
Where would you like me to send the account info to? And do you need sudo access to anything?
| |
Send the info to [email protected]. I don't need sudo but I'd like the host files to be installed in my directory so I can just run the debugger from there. Then I can host a session and debug it when it crashes/uses cpu (you'll have to let me know).
| |
I've sent the login info. Don't hold your breath for a crash since it seems to be a rare occurrence. The CPU spike should occur within a few hours though. I'll let you know when either occurs.
| |
Ok, it's hosted with some newer binaries. If this doesn't give better info, there's another test I can run.
| |
Took longer than I expected, but it's running at 100% now.
| |
Can you install gdb on your machine? Then I can take a look at the running process.
| |
Done.
| |
Thanks. I've gathered some information but would like to debug this more later this afternoon, if you don't mind keeping it running. You can always suspend/resume it if it is causing problems.
| |
The process crashed, looks like in a related point. I'll see if I can figure out where it's going nuts today; if I can't, I'll upload another binary with more debugging info so we can give it another go.
| |
I think it crashed again.
| |
I have uploaded another version with slightly better debugging and am hosting once again. Let me know when it lags or crashes.
| |
Tom has had success sussing out some of these issues when a core dump is available. If you can get your machine to do a core dump when DD crashes, that might be something we could use to figure out the true cause of the crash.