Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ctrlfrk]

Wow... when did this forum fill up with jackasses?
If you don't want to test it, press the back button and go on your merry way.
Or better yet... rub those two braincells of yours together and look at the title he posted. "Stone Sense." Possibly something to do with sensing stones?

On topic:
I'll give it a try when I get home.
And ty for continuing to make cool utils, don't stop just because some people here are unappreciative.
Hopefully this will prompt Toady to include the same function directly in DF, just like regional prospector

[Jifodus]

0x517A5D:

I recompiled stone_sense with VS9 (Pro) since that's the only C compiler I have installed on my system right now.

From what I understood of the code, it hadn't even started searching for the addresses so DF survived just fine (hadn't even suspended it yet).

The weird part is that I just tried running it from inside the VS9 debugger (after telling it to hande exceptions) and it failed to fail (meaning it worked). When I ran it in OllyDbg, it also worked, but it doesn't work from outside the debugger. Extraneous debugging code generated by the compiler?

I think gcc will handle unknown exceptions with

Code: [Select]

try { }
catch (...) { }syntax, though I don't have cygwin/mingw installed right now to find out.

P.S. A 2 minute feature request for hexsearch (since I'm too lazy to do it myself/distribute it), add a way to search from an arbitrary starting point. It's what I wanted most when working on my automated address & offset finder.

[0x517A5D]

Do you really think that any member of this community could complete this project faster then you if you're already at the testing phase?  Look, you may as well just explain what you're attempting to make it do so your testers know exactly what it should be doing.

Fair enough.  It is indeed "sense what stone is around them."  The type of testers I wanted could easily learn that from the source code, which has a prologue comment:

Code: [Select]

A simple utility for revealing more surrounding tiles when digging.

 Currently VERY overpowered as it reveals 17x17 instead of the normal 3x3.

Nobody could possibly steal the idea and get it done faster, unless you're really not as far along as I'm guessing.

That actually wasn't my concern.

If I was worried, I wouldn't release the source code that shows how I do it.

I was going to give everyone a surprise present.  That's all.  I had no malicious intent, didn't want to create drama, didn't want to poke a wasp nest.

[0x517A5D]

From what I understood of the code, it hadn't even started searching for the addresses so DF survived just fine (hadn't even suspended it yet).

Right, I figured that out later.

The weird part is that I just tried running it from inside the VS9 debugger (after telling it to hande exceptions) and it failed to fail (meaning it worked). When I ran it in OllyDbg, it also worked, but it doesn't work from outside the debugger. Extraneous debugging code generated by the compiler?

Quite possible.  When it crashes, do you get an address?  I have IDA Pro (a legal copy) so that might be useful to me.

I think gcc will handle unknown exceptions with

Code: [Select]

try { }
catch (...) { }syntax, though I don't have cygwin/mingw installed right now to find out.

I tried it and the compiler dodn't like it.  Maybe there's a switch to turn it on.  I'll look into it.  If nothing else, I can just use the C++ compiler and feed it C code.  extern "C" and all that.

P.S. A 2 minute feature request for hexsearch (since I'm too lazy to do it myself/distribute it), add a way to search from an arbitrary starting point. It's what I wanted most when working on my automated address & offset finder.

Absolutely, sounds like a good idea.  It will be in the next beta release.  Start and end limits or start and length?  Hmmm.  I think I'll add a new routine to set limits instead of changing the hexsearch() API again.  I hate hate hate breaking code by changing APIs.

And thank you for the work, especially doing your own compilation instead of just quitting when it crashed.

[Jifodus]

Quite possible.  When it crashes, do you get an address?  I have IDA Pro (a legal copy) so that might be useful to me.

I need to stop making posts when I'm not thinking properly.

I was actually going to include the crash address with that last post. I had even added it, but then I deleted that section for some reason or another.

Code: [Select]

00401108  call        eaxI was also going to use IDA free to analyze what it was doing there. I'm still interested in finding out why when it's run inside a debugger, doesn't crash, but outside it does. I wonder if I didn't properly have VS trap all the exceptions at the first-chance.

I tried it and the compiler dodn't like it.  Maybe there's a switch to turn it on.  I'll look into it.  If nothing else, I can just use the C++ compiler and feed it C code.  extern "C" and all that.

I need to stop making posts when I'm not thinking properly. I keep forgetting that it's C, not C++.

And thank you for the work, especially doing your own compilation instead of just quitting when it crashed.

Well I wanted to know why it crashed. Since I'm lazy, and prefer stepping through source code, I had to recompile it myself.

Edit:
I just realized I wasn't looking far enough back in the stack trace. Here's the full trace.

Code: [Select]

ffffffff()
  stone_sense.exe!0040110a()
  [Frames below may be incorrect and/or missing, no symbols loaded for stone_sense.exe]
  kernel32.dll!7644f4be()
  ntdll.dll!77b985b7()
  ntdll.dll!77b29a14()
  ntdll.dll!77b240f4()
  ntdll.dll!77b79b99()
  ntdll.dll!77b79b6b()
  ntdll.dll!77b5d205()
  ntdll.dll!77b78c14()
  advapi32.dll!77133bae()
  ntdll.dll!77b77f54()
  advapi32.dll!77133bc2()
  msvcrt.dll!77039e04()
  msvcrt.dll!7703ec9d()
  ntdll.dll!77b78a94()
  ntdll.dll!77b4fb7d()
  msvcrt.dll!7703f193()
  msvcrt.dll!7703a366()
  msvcrt.dll!7703ece2()
  msvcrt.dll!770431ce()
  msvcrt.dll!77093c6c()
  msvcrt.dll!770402be()
> stone_sense.exe!004012b8()
  kernel32.dll!763f4911()
  ntdll.dll!77b5e4b6()
  ntdll.dll!77b5e489() The one marked with a '>' is apparently the entry-point into mingw's "main" code (__mainCRTStartup, I think, I haven't really looked into it much).

[KaelGotDwarves]

I just wanted to note some gratitude for this project. Anyone who was complaining who didn't know 0x517A5D was the original programmer for Regional Prospector (now implemented in DF) needs to shut it.

[0x517A5D]

Beta 1 has been deleted, Beta 2 is up at http://dffd.wimbli.com/file.php?id=534.

It adds error trapping to help diagnose this mysterious crash.  No other user-visible changes.

[Jifodus]

I've tried it again, and it crashed in the same way again.

This time I recompiled it with Cygwin using the Makefile you provided and whatever version of gcc & w32api that came up as default 30 or so minutes ago when I installed Cygwin. It worked.

Since I believe I've forgotten to include it before, I've been using Vista. I didn't/don't have an XP install immediately handy, though I can reboot by desktop to find out.

The behavior of the crash seems to indicate that it's being caused by incorrect code generated (if I'm not misinterpreting the call stack, it's crashing in the main function), possibly the stack gets messed up from the call to OutputDebugString, however, that still doesn't explain why it works inside a debugger.

I'm finding it hard to debug the exact cause, since I can't replicate it and nor can I get to occur while I'm debugging it. I'll see about writing a custom unhandled exception filter and getting the crash information that way.

Edit: A new dimension to the problem:
If I launch it from the console, it doesn't crash.
If I launch it from explorer, it crashes.
If I launch it from run, it crashes.

[0x517A5D]

I'll see about writing a custom unhandled exception filter and getting the crash information that way.

Won't work, I expect, as I've already put one into beta2.  It was supposed to offer to email debug information to me.

Tomorrow I'll borrow a Vista disk from work and install it in a VM later this week.  I run XP Pro as my desktop, and have everything from Win98 through 2003 Server as VMs, but I don't have a Vista VM handy.

This is weird.  I'm using the latest updated Cygwin as of Sunday.  It has to be the same... why would recompiling make the thing start working?

And apparently the exception handler I added isn't being reached.  That also seems weird.

Antivirus interference?

I think I'm going to switch to vanilla MinGW instead of cross-compiling using Cygwin.  That might make a difference.


Edit: Works from commandline, not elsewhere?  I just tried all three ways, they worked for me.  It sounds like something doesn't work under Vista because I am not creating a window at all?

I'll switch from -mwindows to -mconsole and put up a beta3.

Edit2: Or you could PM me an email address.

[Jifodus]

I'll see about writing a custom unhandled exception filter and getting the crash information that way.

Won't work, I expect, as I've already put one into beta2.  It was supposed to offer to email debug information to me.

Tomorrow I'll borrow a Vista disk from work and install it in a VM later this week.  I run XP Pro as my desktop, and have everything from Win98 through 2003 Server as VMs, but I don't have a Vista VM handy.

This is weird.  I'm using the latest updated Cygwin as of Sunday.  It has to be the same... why would recompiling make the thing start working?

And apparently the exception handler I added isn't being reached.  That also seems weird.

Antivirus interference?

I think I'm going to switch to vanilla MinGW instead of cross-compiling using Cygwin.  That might make a difference.


Edit: Works from commandline, not elsewhere?  I just tried all three ways, they worked for me.  It sounds like something doesn't work under Vista because I am not creating a window at all?

I'll switch from -mwindows to -mconsole and put up a beta3.

Edit2: Or you could PM me an email address.

I'll send my email via PM.

I don't use an Antivirus program, because I've successfully deluded myself into believing that I don't/won't get virii since I'm reasonably careful what I download and run.

It my unhandled exception filter did work. I took a convoluted path for replacing SetUnhandledExceptionFilter to ensure mine would execute first (allowing me to bypass mingw's). I also noticed that my attempt to install a fake exception frame handler also failed. It might've had something to do with

Code: [Select]

1>c:\users\me\documents\visual studio 2008\projects\user32\hook.cpp(107) : warning C4733: Inline asm assigning to 'FS:0' : handler not registered as safe handlerI don't know if gcc emits safe handlers or not, but C4733 could also be the reason why yours didn't work. Apparently executables can contain a list of valid SEH addresses, and if it's not on that list, then it won't accept it.

When I got Windows to break inside my UnhandledExceptionFilter, I found out where it was crashing: ntdll.dll!@RtlpCreateSplitBlock@28 + 0x51

The pretty stack trace with my exception handler at the top.

Code: [Select]

USAR32.dll!TopLevelExceptionFilter(_EXCEPTION_POINTERS * ExceptionInfo=0x0022f880)  Line 116 C++
  kernel32.dll!_UnhandledExceptionFilter@4()  + 0x135 bytes
  ntdll.dll!___RtlUserThreadStart@8()  + 0x3a128 bytes
  ntdll.dll!@_EH4_CallFilterFunc@8()  + 0x12 bytes
  ntdll.dll!ExecuteHandler2@20()  + 0x26 bytes
  ntdll.dll!ExecuteHandler@20()  + 0x24 bytes
  ntdll.dll!_KiUserExceptionDispatcher@8()  + 0xf bytes
> ntdll.dll!@RtlpCreateSplitBlock@28()  + 0x51 bytes
  ntdll.dll!@RtlpAllocateHeap@20()  + 0x348 bytes
  ntdll.dll!_RtlAllocateHeap@12()  + 0x2eac bytes
  msvcrt.dll!_malloc()  + 0x57 bytes
  stone_sense.exe!00401b06()
  [Frames below may be incorrect and/or missing, no symbols loaded for stone_sense.exe]
  msvcrt.dll!__msize()  + 0x45 bytes

[0x517A5D]

It my unhandled exception filter did work. I took a convoluted path for replacing SetUnhandledExceptionFilter to ensure mine would execute first (allowing me to bypass mingw's). I also noticed that my attempt to install a fake exception frame handler also failed. It might've had something to do with
[...]
I don't know if gcc emits safe handlers or not, but C4733 could also be the reason why yours didn't work. Apparently executables can contain a list of valid SEH addresses, and if it's not on that list, then it won't accept it.

Wow.  First I've heard of that.  I knew x64 had something like that, but not x86.  Neat.  But troublesome.  I'll have to remember that.

I'm pretty sure, though, that GCC 3.4.x doesn't support it.  It's too old.  And, frankly, development of GCC tends to lag; it's never cutting-edge.

Code: [Select]

> ntdll.dll!@RtlpCreateSplitBlock@28()  + 0x51 bytes
  ntdll.dll!@RtlpAllocateHeap@20()  + 0x348 bytes
  ntdll.dll!_RtlAllocateHeap@12()  + 0x2eac bytes
  msvcrt.dll!_malloc()  + 0x57 bytes


Malloc!  Why would malloc throw?  Okay, There are two mallocs in main().

Code: [Select]

myname = malloc(strlen(argv[0] + 2));
[...]
myininame = malloc(MAX_PATH+8);

And those are the only two stdlib.h *allocs in the program.

Okay, hmmm.  Those look reasonable to me.  But at least one of them doesn't work.  Fine.  They both can be replaced with fixed-size MAX_PATH based buffers.

That maybe explains why the code works when run in the debugger.  Under Unix/Linux, malloc behaves differently under a debugger, in that it fills the requested area with a 0xDEADBEEF-type pattern, and a few bytes beyond the area with a different pattern.  Maybe MSVCRT does the same thing, checking IsDebuggerPresent.

Okay, I just sent you a couple builds without malloc calls, and a third that deliberately crashes itself.

[Jifodus]

The two work like the first two should have. The third crashes as expected and gives the option to send the error.

The malloc that causes the crash is the second one: myininame = malloc(MAX_PATH+8);
Since it manages to get to: d_printf("I am %s, timestamped %08X\n", myname, mytimestamp);

Which probably means that myname is overwriting it's buffer........

And it is:

Code: [Select]

myname = malloc(strlen(argv[0] + 2)); // <<< you had, strlen of (argv[0] + 2)
myname = malloc(strlen(argv[0]) + 2); // <<< should be, (strlen of argv[0]) + 2


[0x517A5D]

Which probably means that myname is overwriting it's buffer........

And it is:

Code: [Select]

myname = malloc(strlen(argv[0] + 2)); // <<< you had, strlen of (argv[0] + 2)
myname = malloc(strlen(argv[0]) + 2); // <<< should be, (strlen of argv[0]) + 2


Oopsie....

You know, I stared and stared at that and just did not see the problem.

I guess that's why Extreme Programming calls for two-person teams.


Edit: And wouldn't you know it, that was before I installed my SEH handler.  Just before.

Back to IDAPro then.

[ctrlfrk]

This is awesome. Seriously.

1: It can reveal features (underground river/magma) and still trigger the discovery. So magma buildings are enabled, towercaps/cave spiders start appearing.

2: It detects "wet"/"warm" stone heaps in advance, so you don't have to keep redesignating when you dig under a river/magma room.

It's like reveal on steriods, all the good, none of the bad.

I tested beta 3 over the weekend, haven't seen any bugs yet.

At the moment it does look a little rough and haxy, if you manage to get it to scale with miner skill, and maybe round off the edges so it doesnt look so "square", then i think it will be perfect.

Thanks man.

[0x517A5D]

Thank you for the feedback.

You know, it's been downloaded 40+ times, and two people have let me know that they're using it.  Hmm.

I'm making reasonable progress on getting it to scale with miner skill.

Making it round instead of square is, unfortunately, right out.  The code I'm hijacking uses a 3x3 square.  It would be barely possible for me to change loop limits on the fly, but I'm looking for the most gain for the least pain, so I don't intend to try.