www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Is there something special about globals I don't understand?

reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Using DMD 0.121.... the following code compiles and runs fine:













Where mysql.d is a ported version of mysql.h.  However, if I change it 
to the following:















I get an access violation.  Commenting out the mysql_real_connect() and 
mysql_close() calls removes the access violation - so it's not 
mysql_init (which gives me the pointer.)

I thought maybe it was the garbage collector or something (note that I 
do not own the memory mysql points to), but even setting mysql to null 
before the return seems to crash.

I doubt this is a bug or anything, rather it's likely something that's 
not coming to mind just now.  Anyone willing to reveal my ignorance?

-[Unknown]
Apr 17 2005
next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
I've played with this a bit more, and if I do this:


















Yes, that's right, I'm deleting a null pointer.  IMHO, that should be an 
error.  The funny thing is... it no longer crashes like this.  If I 
don't delete the pointer, (even if I still declare it) it crashes.  I 
can also call mysql_free_result() on it, and that will also stop it from 
crashing.

Now I'm beginning to worry it's the GC again.  I mean, the only possible 
thing deleting a null pointer could do is make the garbage collector 
bounce around.

And, just to make things stranger: if I stick those two lines in another 
function, and call the function from main... it goes back to crashing. 
Clearly, it is my intention to be able to run queries from functions, 
not from the main() function only.  I should note that, as long as I do 
those two lines in main(), I can run queries elsewhere too.

Please forgive me for replying/talking to myself.  It's a bad habit - 
comes from instanity.  Sorry.

-[Unknown]
Apr 17 2005
prev sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
I found the problem, looking into it again today.  I was using the 
ported headers available from the links page.

However, these ported headers replaced "unsigned long" with "ulong", 
which was incorrect.  After replacing "ulong" with "uint", everything 
works fine.  As it turns out, I WAS writing to memory I shouldn't have been.

Allocating something extra on the stack was enough to give me something 
to overwrite.  Apparently, it wasn't bothering if I didn't use it; which 
is why I had to delete it.  In retrospect, I see I could have assigned 
it a dummy value too.

I'll try to send an email to the author at some point so he can correct 
this problem.

-[Unknown]
Apr 17 2005
parent Manfred Hansen <manfred toppoint.de> writes:
Unknown W. Brackets wrote:

 I found the problem, looking into it again today.  I was using the
 ported headers available from the links page.
 
 However, these ported headers replaced "unsigned long" with "ulong",
 which was incorrect.  After replacing "ulong" with "uint", everything
 works fine.  As it turns out, I WAS writing to memory I shouldn't have
 been.
 
 Allocating something extra on the stack was enough to give me something
 to overwrite.  Apparently, it wasn't bothering if I didn't use it; which
 is why I had to delete it.  In retrospect, I see I could have assigned
 it a dummy value too.
 
 I'll try to send an email to the author at some point so he can correct
 this problem.
 
 -[Unknown]
Yes please send me an email. Manfred
Apr 18 2005