Mudlet - Forum

It might take a bit to figure out exactly where it originated, but i'm having current compiles of branch_30 crash.

It starts properly, and I can connect to a new profile with no problems. At that point, it connects to the desired mud, and I install my script package. The script files are visible as being installed. I then restart mudlet.

On restart, when I attempt to connect to the profile I just created, it opens the initial mud window (black screen), never displays anything to it and a second or two later gives a non-specific windows error (Mudlet has stopped working) and crashes.

This is happening with both branch_30 and compiling (release_30)bugFix: fix crash on profile auto-load directly. I had compiled branch_30 previous to #319 merging, and it also crashed. At that time, i'd compiled (release_30)bugFix: fix crash on profile auto-load (and it didn't crash ). While it didn't crash previously, now it does crash? Both of the source patches i'd adjusted for compiling with 5.6 when I built them (I overwrote main.cpp and src.pro with the branch_30 copy)

(edit)

Just compiled mudlet-development, same thing is happening (it crashes when it attempts to load the script). I know this definitely wasn't happening when I compiled back in May

Speaking of your May compile, for some reason if I minimize all the windows, switch to some other program, then switch back to Mudlet, no window is made visible (in Mac OS, most recent version), which is contrary to the standard behavior of programs on Macs. Once something stable is put together again, I'd be happy to see if this behavior persists, but if it does, it needs to be fixed.

Looking - Windows event log indicated it was in lua51.dll / exception code 0xc0000005 - I'm going to recheck the compile.

The issue I found in the profile auto-load crashing case was due to something not being explicitly initialised (a pointer that was checked for NOT being NULL before it was used - as that obviously will cause an immediate crash, but in the case of using the autoloading feature it was never set to be NULL to start with - it was just some random value that passed the initial check (it wasn't NULL) but did not actually point to anything meaningful, and under those conditions all bets are off. I have to say I suspect you are witnessing something similar - the fun part will be trying to find out where it is happening - which is why running it in a debugger is so useful so you can set what the state of things are at the point when it crashes and then try and work out what is not right.

Unfortunately the crash happened in the lua51.dll but you can bet that wasn't where the problem is - can you get a stack backtrace to see what Mudlet function was (probably indirectly) calling that function in the lua51.dll?

env = assert (luasql.sqlite3()) - works properly, creating the sql environment
conn = assert(env:connect(pathto toril.db.2015_10_10) ) - works properly, opens sql database

recs = assert(conn:execute([[SELECT item_name, short_stats FROM items WHERE item_type = 'potion']]))

This line (executing the select against the database) crashes. I'm almost finished rebuilding branch_30 right now with Qt 5.4.2, though i'm inclined to think it's something that was changed rather then switching compiler (that was just a co-incidence).

display(env) or display(conn) both show the correct information i'd expect to see if the sqlite dll was loaded properly.

OK I just completed a full build of the current branch_30 using Qt 5.4.2

I also made a couple minor adjustments to the make recipe to match the same versions as my previous build ( and temporarily deleted the line in main.cpp that had been added for 5.6)

It compiled/built properly/ and is running with no problems: I build using the instructions i'd previously posted. It'll probably take a bit to figure out exactly what causes it to occur, but for now epsilon should probably be built with 5.4.2 rather then 5.6

I updated the compile instructions in the wiki yesterday, and am running a 5.6 compile of branch_30 with no problems. I'd made a couple changes in the compile instructions re: libraries it was linking.

Big thanks Nyyrazzilyss for getting the Windows compile going again!

Jor'Mox wrote:Speaking of your May compile, for some reason if I minimize all the windows, switch to some other program, then switch back to Mudlet, no window is made visible (in Mac OS, most recent version), which is contrary to the standard behavior of programs on Macs. Once something stable is put together again, I'd be happy to see if this behavior persists, but if it does, it needs to be fixed.

Hmm... are you certain it is contrary? I'm testing on Sierra and Apple's own Safari and Finder are showing this behaviour, along with other third-party apps. It's mildly annoying but who am I to question Apple's designers...

Well, it turns out you are right (and I'm apparently just used to the behavior of some particular programs on my Mac that do this, as opposed to some Apple programs that don't do it). However, there is one particular issue that is definitely a problem, and remains in the newest (kappa) version you had me test. When I right click on the Mudlet icon in the dock, there is no list of windows to select from, which is doubly a problem because once I minimize the scripts window, clicking the scripts button in the toolbar doesn't restore it. Consequently, the only way to restore the window is to right click the icon and select "Show All Windows".

Yep confirmed.