On Sun, 23 Sep 2018 at 22:15:24 +0200, Adam Wolk wrote:
> Hi ports@
>
> I have a WIP update of games/yquake2 taking it from 7.21 to 7.30 here
> https://gist.github.com/mulander/a749cb99590619748c141161c830dbeb
>
> Testing revealed that the default ref_gl1 renderer results in the game
> failing to start while other renderers work.
>
> Reproduction (unfortunately requires the game data files)
>
> $ quake2 +set vid_renderer gl1 # crash
> $ quake2 +set vid_renderer gl3 # OK
> $ quake2 +set vid_renderer soft # OK
>
> I re-tested on 7.21 and all above renderers worked.
>
> I think the problem is with ld.so behavior on OpenBSD but I'm not sure
> how to debug this further and would appreciate any help. Here is how I
> arrived at this conclusion:
>
> The crash indicates that symbols from glapi are not found
> https://gist.github.com/mulander/223ff586976e61707ee5581156f1369e
>
> ... snip ...
> quake2:/usr/X11R6/lib/modules/dri/i965_dri.so: undefined symbol '_glapi_set_context'
> quake2:/usr/X11R6/lib/modules/dri/i965_dri.so: undefined symbol '_glapi_set_dispatch'
> libGL error: unable to load driver: i965_dri.so
> ... snip ...
Can confirm! vid_renderer set to gl1 causes the following:
quake2:/usr/X11R6/lib/modules/dri/i965_dri.so: undefined symbol
'_glapi_Dispatch'
quake2:/usr/X11R6/lib/modules/dri/i965_dri.so: undefined symbol
'_glapi_Context'
.......
quake2:/usr/X11R6/lib/modules/dri/swrast_dri.so: undefined symbol
'_glapi_set_dispatch'
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 155 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)
Value in failed request: 0x0
Serial number of failed request: 115
Current serial number in output stream: 116
AL lib: (EE) alc_cleanup: 1 device not closed
>
> I started comparing both versions with the help of upstream (caedes).
> The game uses dlopen(3) to load ref_gl1.so (their renderer) which itself
> links against libGL.so which in turn links against libglapi.so.
>
> This is true for the new version:
> https://gist.github.com/mulander/f8b3d1e4e82cd0f48edf5096391ac0dd (ldd output)
>
> and the old one
> https://gist.github.com/mulander/0762234a443c2bdb11b5629cf00b1eea (ldd output)
>
> I grabbed a kdump from the 7.30 run
>
> https://gist.githubusercontent.com/mulander/7d99e5195e723b9297e917d092a0b0ef/raw/e70183eb27cf2288df0598490532bb13db0d68f1/7.30%2520kdump
>
> and checked if the differences between the main binary itself could have had
> impact:
>
> https://gist.github.com/mulander/effd79c3cf7e6558cfdbc9a631f9152c (ldd output left one is 7.21)
>
> I finally ran both versions with LD_DEBUG set, both seem to be loading libglapi.so
> via the same depdency chain ref_gl1.so -> libGL.so -> libglapi.so
> however the new one fails and this is where my debugging ability for this issue
> fails (output[1] below). I did a final test by running the game with LD_PRELOAD
>
> LD_PRELOAD=/usr/X11R6/lib/libglapi.so.0.2 quake2
>
> and with the above, the ref_gl1.so renderer works (game launches and is playable).
>
> I would appreciate any help in diagnosing this issue.
>
> Regards,
> Adam
>
> [1]
> 7.21:
>
> https://gist.githubusercontent.com/mulander/7fb326be6848228ef72debe7ea5a7407/raw/30ee52e5458145ca7d9eb85f9e5985b44e9bb306/debug721 (7.21)
>
> ... snip ...
> loading: libGL.so.17.1 required by ./ref_gl1.so
> flags /usr/X11R6/lib/libGL.so.17.1 = 0x0
> ... snip ...
> loading: libglapi.so.0.2 required by /usr/X11R6/lib/libGL.so.17.1
> flags /usr/X11R6/lib/libglapi.so.0.2 = 0x0
>
> 7.30:
>
> ... snip ...
> loading: libGL.so.17.1 required by ./ref_gl1.so
> flags /usr/X11R6/lib/libGL.so.17.1 = 0x0
> ... snip ...
> loading: libglapi.so.0.2 required by /usr/X11R6/lib/libGL.so.17.1
> flags /usr/X11R6/lib/libglapi.so.0.2 = 0x0
> ... snip ...
>
> https://gist.githubusercontent.com/mulander/7fb326be6848228ef72debe7ea5a7407/raw/30ee52e5458145ca7d9eb85f9e5985b44e9bb306/debug730 (7.30)7.30:
>
>
>
--
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
No comments:
Post a Comment