Throw and DebugStop problems

BlitzMax Forums/BlitzMax Programming/Throw and DebugStop problems

HappyCat

(Posted 2005) [#1]

I'm working on a SQLite 3 wrapper - but that's pretty irrelevant. What I'm finding is that without the following line

Global SQLite3_Exec:Int(DBHandle:Int, SQL$z, Callback:Byte Ptr, FirstArgument:Byte Ptr, Error:Byte Ptr Ptr) "Win32"

throwing exceptions shows the error messages as expected and DebugStop works fine.

But if I include the line above the error messages stop showing up and the Throw just stops the program and the Output window says "Process complete", and DebugStop is ignored.

Any ideas?

Edit: Should say that the annoying thing is that the line of code in question actually works fine.

Edit: Tell a lie - DebugStop stops the program dead but doesn't go into debug mode. Debug Build is definetely on and removing that one line gets everything working again.

Edit: Should also mention - I'm still on v1.09 (demo) for now.

HappyCat

(Posted 2005) [#2]

No one else has seen this? Bummer :-(

skidracer

(Posted 2005) [#3]

Edit: Should say that the annoying thing is that the line of code in question actually works fine.

Then I would point the finger at the call back you are passing the function which, if a Blitz function, will also need to have "win32" type so that function uses __stdcall parameter calling convention in order for your native wrapper not to upset the stack. I doubt very much you will be able to call Throw from the callback also (Throw is mentioned in your topic title but not in your post).

I have had some problems with the debugger getting confused when .bmx callbacks are invoked from C++ wrappers but not the kind of meltdown you are describing.

Also, I assume you weren't referring to C++ exceptions because BlitzMax will not be able to link with any code that expects such a language feature.

HappyCat

(Posted 2005) [#4]

I presume when you say "Then I would point the finger at the call back you are passing the function which, if a Blitz function, will also need to have "win32" type so that function uses __stdcall parameter calling convention in order for your native wrapper not to upset the stack." that you mean like:

Global SQLite3_Exec:Int(DBHandle:Int, SQL$z, Callback() "Win32", FirstArgument:Byte Ptr, Error:Byte Ptr Ptr) "Win32"

Function Callback() "Win32"
    blah...
End Function

But it doesn't help anyway :-(

Another thing I should say is that just including the declaration above causes the problems described - I don't have to actually call the function for the problems to begin.

RktMan

(Posted 2005) [#5]

i'm not a 'C'/C++ guru by any stretch ...

are you sure that this isn't some sort of conflict with this library you are linking to and some fancy signal handling stuff that it might be doing internally that messes with Blitz'es ability to do debugging ?

if the lib _were_ doing something fancy, it would probably be doing it when the lib loads, so calling the function wouldn't be the causal, simply starting the blitz exe would do it i would think.

this thought is pulled completley from my rear ... so grain of salt ...

Tony

gman	(Posted 2005) [#6]

not sure if you have seen it yet, but teammonkey has a wrapper for SQLite as well. you may be able to find some inspiration there.

http://www.blitzbasic.com/Community/posts.php?topic=48455

HappyCat

(Posted 2005) [#7]

are you sure that this isn't some sort of conflict with this library you are linking to and some fancy signal handling stuff that it might be doing internally that messes with Blitz'es ability to do debugging ?

No idea about the dll messing with Blitz. Maybe.

if the lib _were_ doing something fancy, it would probably be doing it when the lib loads, so calling the function wouldn't be the causal, simply starting the blitz exe would do it i would think.

Removing the offending line (but leaving lots of other definitions for functions in the dll in place) causes the debugging to go back to normal, and the problem happens whether I call the offending function or not, which is what made me think it was maybe a BMX thing, rather than the dll itself. I'm probably wrong though :-)

@gman - thanks, hadn't seen that (I'd previously done SQLite in B3D and just started converting it to BMX without looking to see if anyone else had done it already :-) - I'll have a look.

HappyCat

(Posted 2005) [#8]

Okay, I've now tried teammonkey's module (which actually compiles the SQLite source into the module rather than dymanically loading the dll as I was doing) and his example code works find (exceptions and debugstop work as expected).

But when I use his module in my code it has similar problems - exceptions still just end the process silently, while DebugStop now works (though Step In ends the process).

So it looks like it's maybe my code ... oh, well, I'll keep looking.