Closed GWRon closed 7 months ago
Release build + gdb information leads to this:
Thread 1 received signal SIGSEGV, Segmentation fault.
0x00007ff60d428f1c in TVTower!PHYSFS_ucs4stricmp ()
(gdb) bt
#0 0x00007ff60d428f1c in TVTower!PHYSFS_ucs4stricmp ()
#1 0x00007ff60d4194e0 in TVTower!PHYSFS_ucs4stricmp ()
#2 0x00007ff60d41ad66 in TVTower!PHYSFS_ucs4stricmp ()
#3 0x00007ff60d41b96c in TVTower!PHYSFS_ucs4stricmp ()
#4 0x00007ff60d424eb7 in TVTower!PHYSFS_ucs4stricmp ()
#5 0x00007ff60d42570e in TVTower!PHYSFS_ucs4stricmp ()
#6 0x00007ff60d4263bd in TVTower!PHYSFS_ucs4stricmp ()
#7 0x00007ff60d29090e in ?? ()
#8 0x00007ff60d0f6ba8 in ?? ()
#9 0x00007ff60d291783 in ?? ()
#10 0x00007ff60cfa7cf8 in ?? ()
#11 0x00007ff60cfa578b in ?? ()
#12 0x00007ff60cc91fd3 in ?? ()
#13 0x00007ff60cc7596c in ?? ()
#14 0x00007ff60cc758eb in ?? ()
#15 0x00007ff60cc77bdc in ?? ()
Tried an older version of my game - just in case "recent" changes made it incompatible. Debug + GDB Build:
0x00007ff7485d476c in GC_stop_world () at C:/Tools/BlitzMax_alt/mod/brl.mod/blitz.mod/bdwgc/win32_threads.c:536
536 if (p -> crtn -> stack_end != NULL && p -> id != self_id
(gdb) bt
#0 0x00007ff7485d476c in GC_stop_world () at C:/Tools/BlitzMax_alt/mod/brl.mod/blitz.mod/bdwgc/win32_threads.c:536
#1 0x00007ff7485c4d30 in GC_stopped_mark (stop_func=0x7ff7485c4c30 <GC_never_stop_func>)
at C:/Tools/BlitzMax_alt/mod/brl.mod/blitz.mod/bdwgc/alloc.c:826
#2 0x00007ff7485c65b6 in GC_try_to_collect_inner (stop_func=0x7ff7485c4c30 <GC_never_stop_func>)
at C:/Tools/BlitzMax_alt/mod/brl.mod/blitz.mod/bdwgc/alloc.c:603
#3 0x00007ff7485cd623 in GC_grow_table (table=0x7ff748a72a58 <GC_arrays+344>,
log_size_ptr=0x7ff748a72a68 <GC_arrays+360>, entries_ptr=0x7ff748a72a20 <GC_arrays+288>)
at C:/Tools/BlitzMax_alt/mod/brl.mod/blitz.mod/bdwgc/finalize.c:114
#4 0x00007ff7485cdc8a in GC_register_finalizer_inner (obj=0x1a89f361bc0, fn=0x7ff7485c08c0 <gc_finalizer>,
cd=0x7ff7488307e0 <brl_map_stringmap_TStringMap>, ofn=0x8d1b3fc3f0, ocd=0x8d1b3fc3f8,
mp=0x7ff7485cd300 <GC_null_finalize_mark_proc>)
at C:/Tools/BlitzMax_alt/mod/brl.mod/blitz.mod/bdwgc/finalize.c:700
#5 0x00007ff7485cec2f in GC_register_finalizer_no_order (obj=0x1a89d437f20, fn=0x1a89d437b00, cd=0x0, ofn=0x0,
ocd=0x8d1b3fc3f8) at C:/Tools/BlitzMax_alt/mod/brl.mod/blitz.mod/bdwgc/finalize.c:835
#6 0x00007ff7485c09e7 in bbGCAllocObject (sz=<optimized out>, clas=0x7ff7488307e0 <brl_map_stringmap_TStringMap>,
flags=<optimized out>) at C:/Tools/BlitzMax_alt/mod/brl.mod/blitz.mod/blitz_gc.c:118
#7 0x00007ff7485accca in bbObjectAtomicNew (clas=0x7ff7488307e0 <brl_map_stringmap_TStringMap>)
at C:/Tools/BlitzMax_alt/mod/brl.mod/blitz.mod/blitz_object.c:49
#8 0x00007ff74840b7c9 in _brl_reflection_TTypeId_Init_SipbTTTypeId (o=<optimized out>, bbt_name=<optimized out>,
bbt_size=<optimized out>, bbt_class=<optimized out>, bbt_supor=<optimized out>)
at C:/Tools/BlitzMax_alt/mod/brl.mod/reflection.mod/.bmx/reflection.bmx.debug.win32.x64.c:14362
#9 0x00007ff748409138 in _brl_reflection_TTypeId_FunctionType_aTTTypeId (o=<optimized out>, bbt_args=<optimized out>)
at C:/Tools/BlitzMax_alt/mod/brl.mod/reflection.mod/.bmx/reflection.bmx.debug.win32.x64.c:1162
#10 0x00007ff748452f1d in brl_reflection_TypeIdForTag (bbt_ty=<optimized out>)
at C:/Tools/BlitzMax_alt/mod/brl.mod/reflection.mod/.bmx/reflection.bmx.debug.win32.x64.c:43173
#11 0x00007ff748949f3e in winmz_header_fields ()
#12 0x000001a89eebb630 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Copied sdl.mod/sdl.mod from an older commit: https://github.com/bmx-ng/sdl.mod/commit/fdc63bb94253b6f6274b6d4789fc32a7fce5809e "Updated to SDL 2.28.0." Which has almost the same name as the commit creating the issue: https://github.com/bmx-ng/sdl.mod/commit/59dce2b650b9d302effef2efa220d3c28e6721f5 which is "Updated to SDL 2.28.0"
and then adjusted sdl.mod/sdlvideo.mod to not use the newly added 2 functions (they are not in use by me anyways - they just are not existing in the old sdl.mod/sdl.mod version):
Rem
bbdoc: Returns whether the window has a surface associated with it.
returns: #True if the window has a surface, #False otherwise.
End Rem
Method HasSurface:Int()
' Return SDL_HasWindowSurface(windowPtr)
Return True
End Method
Rem
bbdoc: Destroys the surface associated with the window.
returns: 0 on success, or a negative error code on failure; call #SDLGetError() for more information.
End Rem
Method DestroySurface:Int()
' Return SDL_DestroyWindowSurface(windowPtr)
End Method
Rebuild that module, compiled my game - and runs.
I added some variables to ForObject
as it else EAVs already when on the "try"-line while doing "step by step" debugging.
Now it fails there:
So it seems to fail as soon as it reaches the "try" there (but for that specific element gameBase:TGameBase
whose TTypeID is tried to get retrieved via Local srcTypeID:TTypeId=TTypeId.ForObject(source)
)
Made some functions of brl.threads public and used it right there - instead of "_guard.Lock()" and it repeatable EAVs there:
Next I removed the "lock" (but kept the assert - so accessing the object but not locking the pthread-mutex): -> EAV when executing the assert
Next I commented out the assert
-> failing now when reaching Try
Commenting out the Try
/Finally
and End Try
and it EAVs when reaching Local k:Int
Edit: using the "TTypeId.ForObject()" earlier in my code - on the same type (TGameBase) ... and it does not segfault in "ForObject" (in that moment ...). When it then finally reaches the code portion that failed earlier ... it fails again.
Sorry for flooding that issue the whole time - just trying whatever might help.
Edit: I removed the "cloning" there (so no call to forObject()) and it continues execution a while - until it reaches
which was called from there: and as the earlier "getters" worked, there was valid data there :D
This sounds more and more as if the sdl update borks up some variables/pointers
Still happens with latest weekly Windows-Build.
Still happens.
@woollybah can you replicate it in your Linux Windows boxes?
I am currently going through the changes beween this sdl-lib version and the one before.
Seems you missed to unregister threads for blitzmax: sdl.mod/sdl.mod/SDL/src/thread/SDL_thread.c:
Current:
/* register with BlitzMax */
BBThread * bbThread = bbThreadRegister(SDL_ThreadID());
/* Run the function */
*statusloc = userfunc(userdata);
/* Clean up thread-local storage */
SDL_TLSCleanup();
Old:
/* register with BlitzMax */
BBThread * bbThread = bbThreadRegister(SDL_ThreadID());
/* Run the function */
*statusloc = userfunc(userdata);
/* unregister with BlitzMax */
bbThreadUnregister(bbThread);
/* Clean up thread-local storage */
SDL_TLSCleanup();
Adding this "change" to the "old code" makes it segfault as experienced with this 2.28.0 commit
I tried to compile my game with a recent BlitzMax NG "daily build" - for windows and received a segfault.
The debug build leads to something which I assume is "incorrect" (red herring - because positions "differ").
1st try: 2nd try:
The segfault happens first with the update to SDL 2.28.0 https://github.com/bmx-ng/sdl.mod/commit/59dce2b650b9d302effef2efa220d3c28e6721f5
Earlier commits compile and do not segfault when doing what segfaults with above commit (or later commits). Windows brings up an EAV - and THEN I could see the debugger panel on the right in MaxIDE, so it seems it stumbles over something.
On Linux I do not receive such segfaults and also the debugger does not kick in. Edit: Mac Monterey, x64 build and runs fine too.