bmx-ng / sdl.mod

SDL backend for BlitzMax
7 stars 6 forks source link

Segfault (debug says "reflection") since update to sdl 2.28.0 #58

Closed GWRon closed 7 months ago

GWRon commented 11 months ago

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: image 2nd try: image

The segfault happens first with the update to SDL 2.28.0 https://github.com/bmx-ng/sdl.mod/commit/59dce2b650b9d302effef2efa220d3c28e6721f5

image

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.

GWRon commented 11 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?)
GWRon commented 11 months ago

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.

GWRon commented 11 months ago

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: image

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))

image

GWRon commented 11 months ago

Made some functions of brl.threads public and used it right there - instead of "_guard.Lock()" and it repeatable EAVs there: image

Next I removed the "lock" (but kept the assert - so accessing the object but not locking the pthread-mutex): -> EAV when executing the assert image

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 image

which was called from there: image 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

GWRon commented 7 months ago

Still happens with latest weekly Windows-Build.

GWRon commented 7 months ago

Still happens. @woollybah can you replicate it in your Linux Windows boxes?

GWRon commented 7 months ago

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:

image

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