Jump to content
  • Advertisement
Sign in to follow this  
ZenDarva

Semi-Random crash problem, need advice.

This topic is 3924 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm having a semi-random crash problem with a program i'm working on. It's a mud, using C, lua 5.1, and swig to bind lua to C. The crash happens when I add code that adds a table to lua. But the crash doesn't happen on the added code. That would be waaay too simple. I'm developing in a cygwin environment, so I used gdb to run the mud, and single stepped through, after the bit of code I added. It returns from my initilization, then goes through my script loading routine until it calls itself recursivly again, then crashes there. The worst part is GDB hangs, and I can't get any information from it. If I don't use gdb then the program crashes at a different location that I've been unable to determine. I tried adding puts("blah"), puts("blah1"), etc as logging statements, but amusingly enough, the mud then refuses to crash, and goes about its business happily. I haven't found anywhere to put an output command that still crashes the mud, which would at least tell me that the crash is happening before the logging command is executed. If I remove the added code entirely, and create the table directly in lua, everything runs fine as well. I would just do that, but this crashing obviously tells me I've got some sort of bug hiding somewhere, and I can't just ignore it. The problem is, I have absolutely no idea how to find the bug, or even what it could be. Does anyone have any sort of suggestions on what to look for, different ways to run GDB so that it doesn't crash, or other programs to analyze the code with? I'm tearing out my hair here. I would post the code, but I obviously have no idea what part to post, and the whole is rather large to post here (around 130k). Darva *edit* I think i must be doing something horrid to the stack, because changes that make no sense to change where it crashes cause crashes. example:
function rFunc:Init()
dRoom = world.droom_data()
dArea = world.get_area_by_uid(areauid)
print("init")
world.init_room(dArea, roomuid, dRoom)
print("here")
dRoom.name = "The Southern Void"
print("here1")
dRoom.desc = "Oddly, you feel a bit warmer here, and a bit more festive.\n\rSomehow, that's creepeir than the regular void."
print("here2")
local dExitNorth = world.dexit_data()
print("here3")
dExitNorth.toroomuid = 1
print("here4")
dExitNorth.fromroomuid = roomuid
print("here5")
dExitNorth.toareauid = 1
print("here6")
dExitNorth.fromareauid = 1
print("here7")
dExitNorth.dir = world.DIR_SOUTH
print("here8")
world.add_exit(dRoom, world.DIR_NORTH, dExitNorth)
print("Done");
end
doesn't crash, but this does:
function rFunc:Init()
dRoom = world.droom_data()
dArea = world.get_area_by_uid(areauid)
print("init")
world.init_room(dArea, roomuid, dRoom)
print("here")
dRoom.name = "The Southern Void"
print("here1")
dRoom.desc = "Oddly, you feel a bit warmer here, and a bit more festive.\n\rSomehow, that's creepeir than the regular void."
print("here2")
local dExitNorth = world.dexit_data()
print("here3")
dExitNorth.toroomuid = 1
print("here4")
dExitNorth.fromroomuid = roomuid
print("here5")
dExitNorth.toareauid = 1
print("here6")
dExitNorth.fromareauid = 1
print("here7")
dExitNorth.dir = world.DIR_SOUTH
--print("here8")
world.add_exit(dRoom, world.DIR_NORTH, dExitNorth)
print("Done");
end
[Edited by - ZenDarva on September 25, 2007 8:25:27 PM]

Share this post


Link to post
Share on other sites
Advertisement
Now, I'm not an expert on GDB, but it sounds like you have a buffer overrun problem somewhere in your code.

The reason you're seeing different behavior based on whether you run it under the debugger or not is that the heap and stack behave differently under the debugger than they do outside of the debugger.

As far as finding it goes...these can be tough. If you can, you should link against the debug CRT, which will allocate guards on either side of variables. You then might be able to make a call into the CRT to do a run-through test of these buffers at any time, say at the end of a suspicious function. The CRT will look through the guards and check whether they have been overwritten. If they have, it will identify the location. For stack overruns, GS cookies do something similar.

Matt

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!