bad refs:obj=$5d2400 refs=$7ffffae9
BlitzMax Forums/BlitzMax Programming/bad refs:obj=$5d2400 refs=$7ffffae9
| ||
| What does this mean? Is it my fault? How can I check out object $5d2400? It just popped in at IDE output console and.. i dont know why.. sounds like an error with refcounting in the gc or something like that. Some more app env info: I got blitzmax v1.33 installed. I yet was not able to reproduce the symptom, so I cant really test whether it works on the most recent max version. The occurance *feels* random. I make massive use of circular references, if that plays a role. The warning or error or whatever it is, does not effect the actual appflow (from my pov). I got constant mem usage, logic updates, it .. runs and keeps outputting this... bad refs:obj=$5d2400 refs=$7ffffae9 bad refs:obj=$5d2400 refs=$7ffffb67 bad refs:obj=$5d2400 refs=$7ffff9a8 'see those last 3 halfbytes changing and changing? uua that makes me nervous considering theres no actual persistent relinking of objects going on in the app. [edit:] Ok, some browsing the forum I should actually have done before posting this tells me, it has something to do with maxgui, which my app uses too. But.. I mean i create one window and a canvas with it then hide the window and .. it's not that I stress it to the limits .. hopeviously (= "hopefully"+ "obviously") L O L [edir2:]NOW it keeps spamming my output with "String:" I DONT HAVE A SINGLE LINE saying Print "String:"Guess I'm just gonna go crazy thinking about this .. |
| ||
| Which version of Maxgui are you using? the latest MaxGUI release also assumes that you are using BlitzMax 1.34... |
| ||
Ok, I us_ed_ 1.32, until I updated 30 minutes ago.. did run my app in the backround keeping an eye on the output console.. now after ~<20 min this popped in again:bad refs:obj=$5d2400 refs=$7ffff6e5 String: So MaxGUI Version has no effect .. This is so ugly not to know where this comes from. I mean, first report of this was like 4 years ago, and its still not cleared. That sucks. |
| ||
| The problem is due to a string that is about to be garbage collected but still being referenced by some piece of non BlitzMax code somewhere - probably/possibly/maybe. Of interest to someone I'm sure, is collectMem() in blitz_gc.c, which has this section, looking remarkably similar to the afforementioned output :
if( p->refs>=0 ){
printf( "bad refs:obj=$%x refs=$%x\n",(unsigned)p,(unsigned)p->refs );
if( (void*)p->pool==(void*)&bbStringClass ){
printf( "String:%s\n",bbStringToCString( (BBString*)p ) );
}
fflush( stdout );
}
:o) |
| ||
| Yea thats.. I dont know if good to know.. thank you despite Brucey.. first really explaining answer I read, and that code really looks like it'd produce the critical output. Now.. the only thing I want to know is, whether this is "dangerous" in any kind. |
| ||
| Based on what Brucy dug out of the garbage collector I'd go looking for somewhere where you set something to null or a string to "", most likely a string somewhere getting set to "" under some odd condition. Possibly this is causing a de-reference of a string you want (I'm guessing you don't notice since it's probably being set to nothing anyway). My out of the blue theory would be that this is a bad thing (since bad memory handling is always a bad thing) but in your instance it might not be fatal (since if I'm correct in my assumption it's involving setting something to null then when you ask for the value of that something and it allocates a new one it will default to null anyway...). But memory is a scary thing to loose control over since that's where computer gremlins live. |
| ||
| Have you considered trying 1.34? It has an entirely different garbage collector as one of the options you can use. (By selecting multithreaded in the compile options) |
| ||
| Theres no point for me switching to threaded compilatiion atm, except for just testing if the new gc involves the problem. Brucey wrote The problem is due to a string that is about to be garbage collected but still being referenced by some piece of [b]non BlitzMax code[b] somewhere .. so as I understood the problem may not being directly triggered in a very direct manner by my string-involving instructions, may it? |
| ||
| Ive written some programs before that used to cause this error to come up about once every second. (multiple versions of bmax) In my case it was related creating, using and destroying many objects in a loop. My program had no external dependencies and no strings were used except for writing to the console and there wasn't much of that going on. I should also note that there was never any memory leaks related to error. Never was really sure what caused the problem. |
| ||
| Thank you all for your replies so far. The answers involve this: - The output comes from maxgui (Forum so far) - The output is triggered when a badly referenced string is to be gc'ed (Brucey) - The output is generated when masses of objects are created in a loop (GW) So best "solution" for this what-is-it? is to ignore it? Ok. Guess I'll have to live with it, until it causes more trouble, and a public fix is out. Not sure whether i really look forward to this moment. |
| ||
| A few month ago I suffered also from this problem when using 1.33. bad refs:obj=$115a2780 refs=$630069 (no string message...) The problem was not present in Bmax 1.30 and earlier, but came with the introduction of the new GC in 1.32. Nevertheless I tracked the problem down to a windows api call/structure – changed that and the problem went away. When looking where the problem might comes from, it is quite difficult because of the time delay until the gc cleans up. For me it worked quite fast to find the problem after I thought about, by using debugstop instead of debuglogging what my program does. Putting the debugstop at several positions and check a few seconds if the gc comes up with the error then try the next... and voila. Don't know if it helps, but may give it a try. |
   |