I am using format$ to format some debug strings and am getting the above error.
I don't get it if i don't use Format$
c$=c$+FORMAT$(3,0,cnt)
x$=x$+FORMAT$(3,0,locs[cnt][1])
y$=y$+FORMAT$(3,0,locs[cnt][2])
h$=h$+FORMAT$(3,0,locs[cnt][3])
if i just add to the string e.g. c$=c$+cnt+" " its fine it just seems to freak when using Format$
can you give full example, then im can tryout on Mac, if its a bug or not. its somewhere a memory access pointer bug, and in which version of glbasic (v12 or v14?).
It's 14.106
I am pm'ing you with the source.
Much appreciated.
:enc:
its a very strange bug, either in FORMAT$() or in PRINT$ (which im do newer use my self, but doing my own, but here its used for debug).
This is such of one im needing testing on my Mac, which will tell where its crash (in the glb source code).
im move it to the bug section, and might rename the subject for easier track.
ok cool
This is one of the more strange bug. Im have not yet moved it to Mac, but its seens to been a bug in glb.h or a command, me thinks.
Im tried to uses BMfont to print it, but its did also crash using that too (which using POLYVECTOR).
Its look like its a String issue, released wrong somewhere. Im not even using FORMAT$.
Yeah it's just seems to be the print command but as i said if you do it with Left$ then it works ok,so maybe weird data at the end of the string almost like a buffer too small.
Im thinking the same. Im looking to move to mac tomorrow. clock too many now. Im also need to move glbasic v14 over too and then testing it on iOS. Here its should tell where its crash and then hint Gernot.
Im do thinks its canbeen some worry about when using objects (im did also tried to GLOBAL it without succes)?
But its look like same sort of issues im did have in Purebasic, when im returned the strings back to BlitzMax. Then its something might crash. Here its some years ago. But its should not crash like this.
Yes, if im using Left$ with a quite low value, its works fine. But im could also not move the string to a another variable or such. A funny part is im can STDOUT it, without seens trouble and its quite very random when its happens.
So im can only thinks the string might release too early?
Just bear in mind, iOS does not like DEBUG command at all (why im used a DEPRINT function so its can send to either DEBUG or STDOUT).
Yeah i tried global too and also noticed it works ok with debug...
Look like there is few issues to been fixed, before xcode can work with glbasic 14. Currectly im doing setup a general test app, so its can been used for testing for any issues, not just for the source code im got for testing this issues, bot also different issues as well. Hopefully its will crash the same on iOS, where the debugger is easier.
Im will send that project (except the game source code of course) to Gernot as well with full glb_source code. Sometimes its simply easier to expose full code when compiling on xCode. Howover the crash on that line might not allways a fix is there.
Im remember its was a totally differnt issue for the first 64bit crash. If that happens, then im might need to send it to HeadKaze, which is expert to fix that kind of issues (without him, ios 64bit would newer been happens, he was a great help for me).
Also when that project is working, then PRESCALER should also work on iOS as well, because im finally updated the codebase to v14 (Android is allready ready, only ios is missing).
Cool,Thanks for the update.
I am now getting loads of
*** Unhandled exception ***
EXCEPTION_ACCESS_VIOLATION errors randomly.sometimes it works,sometimes it doesn't.
im havent looked into this, due there is various other things im need to do, before skivaccation. Im more guess its happens when the string got released too early, so the game crash when trying to access a memory that got released. When that happens, then its crash.
Yes its quite random here as well and absolutte confirmed.
hmm. im just got it running on iOS.
Here its simply crash out in LOADBUMPTEXTURE command (in openglrainbows.cpp). Somtimes its does pass it.
Then its will crash on glDrawArrays(GL_TRIANGLE_STRIP, 0, g_PolyPoints.Size()) in OpenRainbow (before the screen is show).
Since PRINT$ also use POLYVECTOR internal, this might why both mine and PRINT method fails.
UPDATE:
This bug is pretty weird and seens not crash same place, so im need to checkout what happens and im even only using 32bit. But all issues have been "Incorrect checksum for freed object - object was probably modified after being freed", but crash in various points (but with same error).
This is something im need help from HeadKaze (or Gernot) to fix this issue. Is its ok for you to send him the source (ONLY the compiled c++ source is needed, not the glbasic code).
You can send him any of my code as long as it helps find the issue.No Probs!
Im will send it, howover this might cross my skiing vacation in the next week, where im gone for a week. so im might not do anything. But im will send the xCode project.
My guess the but is in glb.h. If its there, then its easy to been fixed without a glbasic update.
Have fun Skiiing! =D
Hi SF,
I have another weird issue that i think might be connected.
On compilation i am getting error : GPC0007 wrong argument type : at line that contains p$=p$+"loop 1"
I suspect there is something in my code that is causing these weird string issues.
Let me know if you or Gernot want my code to try and track down this bug.
FUNCTION playTunes:init
// LOCAL t//=GETTIMERALL()
STATIC settimer//=0
LOCAL cp,cc
LOCAL p$="playing "
STATIC c
cp=tune[c]
IF cp=-99
c=0
cp=tune[c]
ENDIF
cc=bAND(cp,1)
IF cc=1 THEN p$=p$+"loop 1" //error occurs here
IF GETTIMERALL()>settimer
DEBUG "\n swapping"
cc=bAND(cp,1)
IF cc=1
PLAYSOUND (s1,0,1)
ENDIF
cc=bAND(cp,2)
IF cc=2
PLAYSOUND (s2,0,1)
ENDIF
cc=bAND(cp,4)
IF cc=4
PLAYSOUND (s3,0,0.2)
ENDIF
cc=bAND(cp,8)
IF cc=8
PLAYSOUND (s4,0,0.8)
ENDIF
settimer=GETTIMERALL()+29000
INC c
DEBUG "\nloop"
ENDIF
NewOSDebug("Timer"+((GETTIMERALL()-settimer)/1000)+p$)
ENDFUNCTION
OK!
The weirdness continues
If i make the string name longer than 1 character it works ok
i changed p$ to pu$ and it now works.
Something strange is going on...
Im have been and is still currectly sig, some days after the ski vaccation (which was fun), which is why im are a bit away and not have looked in anything at all. Sorry about that. so im have not a change to look into this, but HeadKaze have linked into this post about this issue:
http://stackoverflow.com/questions/19840671/malloc-error-incorrect-checksum-for-freed-object-object-was-probably-mod
This is what im seen, and is also happens on iOS as well. Sometimes its works and sometimes its crash in various points, but all with same issue. So its property a imprompert way a string is released me thinks.
But sadly my c++ knowable might not been that strong to fix this issue, but im is happy to send you the xCode project back for future testing. Im thinks this issue is easiest to been fix on iOS and not in Windows. Im will do take a look later, when im fresh again.
You might allready have a GLOBAL P argument..... Which might have confuced the compiler. dont mix them up in objects.
Ah yes you are right i had a global p hidden away!
Get well soon.