When running any program under wine (e.g. winecfg) on xvnc4server,
assertion fails inside libGL.so.1 from libgl1-mesa-glx package:

glxcmds.c:343: CreateContext: Assertion `mode != ((void *)0)' failed.

A quick look info code shows that it hits a 'FIXME':

 ...
   337              if ( fbconfig == NULL ) {
   338                  /* FIXME: Is it possible for the __GLcontextModes structure
   339                   * FIXME: to not be found?
   340                   */
   341                  mode = _gl_context_modes_find_visual( psc->configs,
   342                                                        vis->visualid );
   343                  assert( mode != NULL );
   344                  assert( mode->screen == screen );
   345              }
 ...

Could you try with libgl1-mesa-glx 6.5.2-3 currently in experimental? The
FIXME code seems to still be there, but maybe something else has been added
to work around the problem...

If it still fails, it should be reported upstream.

Brice

Yes, same thing with version from experimental.

Hi Nikita,

could you install the -dbg package and get a stack trace with gdb when
the problem happens?

Cheers,
Julien

formats, and gdb is confused and does not show anything useful:

...
e/skel/c/windows/winhelp.exe: glxcmds.c:343: CreateContext: Assertion
`mode != ((void *)0)' failed.

Program received signal SIGABRT, Aborted.
0xb7f07410 in ?? ()
(gdb) where
#0  0xb7f07410 in ?? ()
#1  0x0033ec38 in ?? ()
#2  0x00000006 in ?? ()
#3  0x00006cfb in ?? ()
#4  0xb7caa811 in ?? () from /lib/tls/i686/cmov/libc.so.6
#5  0xb7cabfb9 in srandom_r () from /lib/tls/i686/cmov/libc.so.6
#6  0x00000006 in ?? ()
#7  0x0033ecd8 in ?? ()
#8  0x00000000 in ?? ()

Wine's internal debugger shows more:

Backtrace:
=>1 0xb7ffd410 (0x0034ecb8)
  2 0xb7da1fb9 abort+0x109 in libc.so.6 (0x0034ede4)
  3 0xb7d99fbf __assert_fail+0x10f in libc.so.6 (0x0034ee28)
  4 0x7e71aac6 in libgl.so.1 (+0x1cac6) (0x0034ee68)
  5 0x7e71abf2 glXCreateContext+0x32 in libgl.so.1 (0x0034ee88)
  6 0x7e8e7c2a in winex11 (+0x37c2a) (0x0034ef08)
  7 0x7e8e839a X11DRV_setup_opengl_visual+0x3a in winex11 (0x0034ef98)
  8 0x7e8fdc11 in winex11 (+0x4dc11) (0x0034f0e8)
  9 0x7e90dd95 in winex11 (+0x5dd95) (0x0034f108)
  10 0x7bc37d55 call_dll_entry_point+0x15 in ntdll (0x0034f128)
  11 0x7bc38e49 in ntdll (+0x28e49) (0x0034f1d8)
  12 0x7bc392fd in ntdll (+0x292fd) (0x0034f218)
  13 0x7bc3b447 LdrLoadDll+0x87 in ntdll (0x0034f248)
  14 0x7b86089b in kernel32 (+0x4089b) (0x0034f498)
  15 0x7b860a9c LoadLibraryExW+0x4c in kernel32 (0x0034f4c8)
  16 0x7b860bc1 LoadLibraryExA+0x41 in kernel32 (0x0034f4e8)
  17 0x7b860bf9 LoadLibraryA+0x29 in kernel32 (0x0034f508)
  18 0x7ec265a0 DRIVER_load_driver+0x1c0 in gdi32 (0x0034f678)
  19 0x7ec2222e CreateDCW+0x6e in gdi32 (0x0034f928)
  20 0x7ecee9ff CreateIconFromResourceEx+0x45f in user32 (0x0034f9d8)
  21 0x7ecef3af in user32 (+0x2f3af) (0x0034fa38)
  22 0x7ecef91d LoadImageW+0x42d in user32 (0x0034fae8)
  23 0x7ecf0053 LoadImageA+0x53 in user32 (0x0034fbc8)
  24 0x7ecf02f2 LoadCursorA+0x42 in user32 (0x0034fbf8)
  25 0x7ece5f45 in user32 (+0x25f45) (0x0034fc28)
  26 0x7ece5f9d CLASS_RegisterBuiltinClasses+0x1d in user32 (0x0034fc38)
  27 0x7ed59fe1 in user32 (+0x99fe1) (0x0034fcb8)
  28 0x7ed6cde5 in user32 (+0xacde5) (0x0034fcd8)
  29 0x7bc37d55 call_dll_entry_point+0x15 in ntdll (0x0034fcf8)
  30 0x7bc38e49 in ntdll (+0x28e49) (0x0034fda8)
  31 0x7bc392fd in ntdll (+0x292fd) (0x0034fde8)
  32 0x7bc39242 in ntdll (+0x29242) (0x0034fe28)
  33 0x7bc3c102 LdrInitializeThunk+0x382 in ntdll (0x0034ff08)
  34 0x7b86ee75 in kernel32 (+0x4ee75) (0x0034ffe8)
  35 0xb7ec37a7 wine_switch_to_stack+0x17 in libwine.so.1 (0x00000000)

That's enough to find point inside wine sources from where call to libGL
happens, in is inside X11DRV_setup_opengl_visual().

Nikita

Nikita V. Youshchenko wrote:

Ok, not very useful.

Would you mind reporting all this upstream at
https://bugs.freedesktop.org/index.cgi, product Mesa, component GLX? If
you can't, let me know, I take care of it.

Thank you
Brice

forwarded 415292 https://bugs.freedesktop.org/show_bug.cgi?id=10488
thanks

Done

Hi Nikita,

It might be good to test Mesa 6.5.3-1 which has been uploaded to
experimental today. The upstream bug that you reported has not been
touched, but there are so many changes since 6.5.2 that it's probably
worth a try.

Brice

Hello, and sorry for long delay.
I've tried it, and the issue is not fixed. Wine started on Xvnc4 16bpp
session still gets same assertion failure.

However, I found that wine works OK (at least without assertion failure
being discussed) on Xvnc built from fedora sources (which is based on Xorg
7.x, while debian's Xvnc4 is based on Xfree 4.x).

Hi Nikita,

upstream bug report was closed with:
"This code has been rewritten since and almost certainly fixed, closing."

Can you try with a recent Debian system and report back?

Thanks.

At 2023-01-02T18:54:02+0100, Fabio Pedretti wrote:

Jesus.  I'd never trust a claim like that without output from a formal
verification suite to confirm it.

I think we may have a brogrammer at play.

Regards,
Branden

forwarded 415292 https://gitlab.freedesktop.org/mesa/mesa/-/issues/49
thanks

Il giorno lun 2 gen 2023 alle ore 19:03 G. Branden Robinson
<g.branden.robinson@gmail.com> ha scritto:

Well, this Debian bug report is over 15 years old. :)

Il giorno lun 2 gen 2023 alle ore 19:03 G. Branden Robinson
<g.branden.robinson@gmail.com> ha scritto: