building from source

[Moorea]

thx, updated the faq some more

about the crash I can somewhat reproduce it by

- starting 2 wow windows on main pc
- starting mojo (from VC debugger)
- starting mojo on 2nd pc

"doing something else" on main pc (like typing in the faq)

earlier; before I cleared my settings, it was happening all the time at each launch of the 2nd mojo but I also had the 2 wow windows logged in and playing; so I'm not sure exactly which parameter makes it harder to reproduce - have you seen that error before - is it useful I try to reproduce it ?

[Freddie]

thx, updated the faq some more

about the crash I can somewhat reproduce it by

- starting 2 wow windows on main pc
- starting mojo (from VC debugger)
- starting mojo on 2nd pc

"doing something else" on main pc (like typing in the faq)

earlier; before I cleared my settings, it was happening all the time at each launch of the 2nd mojo but I also had the 2 wow windows logged in and playing; so I'm not sure exactly which parameter makes it harder to reproduce - have you seen that error before - is it useful I try to reproduce it ?

The only crash I ever see is when I debug a release build. The debugger crashes at a certain place in the source. I think it's a bug in the debugger.

The program shouldn't be able to crash because it has a "last resort" crash handler that should intercept any exception. Worst case, in the debugger, the program should generate an exception. Outside the debugger, the program should show a dialog box asking the user to send me a minidump.

The code that displays the WoW icons is unfinished and it's quite possible it has a null pointer error in it or something like that. But it shouldn't make the debugger crash. It should just generate an exception.

To switch to a debug build, go to Build : Configuration Manager : Active Solution Configuration.

[Moorea]

I thought I had found a simpler repro sequence but it actually doesn't really always happen right away, here it is anyway:

erase all settings on both computers

start mojo from debugger (start new instance) on main pc; accept license
start mojo on 2nd computer; accept license

go to mouseover settings and connect the 2 screen (I used my main on the right of the 2nd pc; if that matters)

using mouseover start wow on 2nd pc

start wow on first pc

type stuff on bot password boxes

setup pause has windowbroadcast toggle; use it on/off a few times

toggle wow from windowed to fullscreen and back

type some more

crash

[Freddie]

It just occurred to me that the crash could be happenin before the last-resort crash handler gets installed.

Is this happening in the debugger ?

[Freddie]

Which one is crashing? The one that's running in the debugger?

Is it literally crashing or is the debugger stopping at an exception?

Are you debugging a release build or debug build?

[Moorea]

it's just going into the debugger with no visible source stack trace - it was just running the default "start new instance" under debug - I'm now "running" the release (without debugger) and I haven't seen any complaint (do you have a log file where messages like
HEAP[mojo.exe]: HEAP: Free Heap block 20efa68 modified at 20efa90 after it was freed
would go when starting from windows normally ?)

[Freddie]

it's just going into the debugger with no visible source stack trace - it was just running the default "start new instance" under debug -

If it crashes in a way that opens the debugger, it won't be running in the debugger. There's a window that shows the call stack but I think it's closed by default. To see it, you probably have to go to Debug : Windows and select the Call Stack window.

(do you have a log file where messages like
HEAP[mojo.exe]: HEAP: Free Heap block 20efa68 modified at 20efa90 after it was freed
would go when starting from windows normally ?)

So far as I know, that particular error only gets noticed in debug builds and when they happen, the debugger breaks in and displays a dialog box, so I don't bother logging them.

Most errors that can occur in release builds get logged in two files in

%localappdata%

If a memory error causes a crash, the program's "last resort" exception handler should be creating a mini dump with crash data including the address of the error. When the debugger gets called up automatically like it's doing for you, I think it already has the crash dump loaded.

You're running your own build, right, so the debugger should have all the symbol tables etc. that it needs to show you everything.

You can run the program in the debugger to begin with. That way when it crashes it will just stop wherever it crashed.

Open the Call Stack window (explained above) and you should be able to see instantly where it crashed.

[Freddie]

Moorea, I wonder if you're just hitting an assert(). If you hit one, it drops you into the debugger. If that happens the debugger should show you a dialog box when it comes up asking you what you want to do.

I think the dialog box offers you "Abort" and "Retry." Click Retry. Then another box. Click "Break."

Now you can look at the call stack (but you have to open the window as described above).

You should find yourself in Microsoft CRT library code looking at a function called (I think) _wassert.

[Freddie]

another problem I have is soon after I start another mojo on another computer I get thrown in the debugger:

HEAP[mojo.exe]: HEAP: Free Heap block 20efa68 modified at 20efa90 after it was freed
Windows has triggered a breakpoint in mojo.exe.

I'm sorry, I overlooked this post. This whole time we've been talking about the crash, I didn't realize you had gotten this error message. You mentioned it again later but I thought you were making up an example.

Please ignore everything I said above about exceptions, the debugger, etc.

You found the cause of the crash. I don't what else you can do. I mean, if you want, of course you can try to find the place in the code where the memory gets overwritten but since you're not familiar with the code or the debugger I think it would be amazingly hard.

[Freddie]

I get some errors while running, opening the mouseover_blue.jpg and mouseover_gray.jpg - seems like those 2 are installed by the installer - anyway to put them with the rest of the resources ?

I think the program loads them from its own folder (the folder with the EXE) at run time. SVN puts them in the mojo_art folder.

Just copy them into the folders with the EXE's. The release EXE is in the Release folder. Debug build is in Debug folder.