gdb in windows is pretty flaky.. if you can't get it to work, you might go to the time-honored tradition of putting printf's all over the place and finding the last thing it prints before dying.. your bug is somewhere between that and the next printf. Then you can narrow it down.
> Again, GDB only has ONE purpose.. To detect WHY the mud crashed, that's all.. > GDB simply pours through core dumps to find out why the mud crashed. Nothing > else. Well, gdb in cygwin doesn't provide any kind of parsing of core dumps the way it does in Unix. To find out why it crashed, you really have to run gdb attached to the mud's process. There are several ways to do this, read the gdb man pages. > GDB is used to tell why the core dumped, AFTER the mud crashed, NOT to run > the mud, first off. gdb can really do a whole lot more than look at core dumps.. like looking at memory locations during run time, setting break points, etc.. One way to do this is start the mud from within gdb. > ANYONE can run their mud on a unix/linux box. The question is are you willing > to learn it? Most aren't willing to do that. Some people may not be able to afford a shell account.. I think cygwin is a reasonable development environment, though it's probably a poor choice for actually running a mud (last time I checked, cygwin only allows for 32 file descriptors). From what I can tell, recent versions of cygwin work *very* close to gnu tools. > Learn what you're talking about, before asking the list stuff Maybe the arrow points both ways.. --Palrich.
