2025.1: Xschem closes and the Xming server crashes every 10 minutes

[MrHighVoltage]

Describe the bug
As the title says.
Tagging also bug report #91

Environment:

• OS: Windows
• Operating mode: X11 with Xming as X-Server
• Version tag 2025.01

[MrHighVoltage]

@simi1505 I haven't used Xming personally for the X-Server, so it is a bit hard to debug. To make it easier:

Did you update Xming also or just the container?
Do the windows just close suddenly, like there is a timeout?

[simi1505]

• I use Windows OS and I have the image and containers in Docker Desktop.

• I run the image with Xming X Server for Windows to run Xschem etc.

• After using Xschem for several minutes it suddenly freezes for some seconds and Xschem and also the Xming Server close. The Xming Server exits completely, so I have to start it again. Not like if I just close the command line and open it again after running the container again.

If it helps, I could come by tomorrow?

Edit 1: The issues occurred with: https://sourceforge.net/projects/vcxsrv/
I now try https://sourceforge.net/projects/xming/, maybe this works better.

Edit 2:
Okay, with https://sourceforge.net/projects/xming/ you cannot enter something in the graphdialog of the embedded Waveform Viewer. This is a huge red flag for me. So I will install https://sourceforge.net/projects/vcxsrv/ again and see what happens.

Edit 3:
With the new installed https://sourceforge.net/projects/vcxsrv/ it works a little bit better but it is still not stable. However what I can tell you: It only crashes if someone works with Xschem. If you just open it and do nothing, Xschem does not crash. Interestingly, it most of the time crashes during scrolling (zooming in and out of the circuit).

[hpretl]

I have reported this to the Xschem maintainer: StefanSchippers/xschem#276

[MrHighVoltage]

Do we already have some kind of error log? Or is this always lost due to the whole X-Server crashing?

[StefanSchippers]

[Edit] Try to follow comments below starting from the last one and going up....

@hpretl @MrHighVoltage It's difficult me to reproduce the environment since I don't have windows computers here, however:
Can you roll back to an older xschem build and see if problem happens again?
For example, after cloning the github xschem repo:

# clone the xschem repository into xschem-src
https://github.com/StefanSchippers/xschem.git xschem-src
# enter the source tree
cd xschem-src
# List all tags
git tag
# Checkout an older tag
git checkout tags/3.4.4
# Configure for build;  --prefix (installation directory) is optional
./configure [--prefix ...]
# Compile
make
# Install; sudo is needed if using the default prefix in /usr/local or installing 
# in any system directory 
[sudo] make install

Running this older xschem will tell us something. If crash happens again then there is likely some issue with the Xserver, or a very long standing bug nobody reported to date.
If the older xschem is stable we can bisect xschem versions and see the commit that caused the problem.
If someone can do this task that would be of great help.
Thank you.

[StefanSchippers]

Another test you can do is using the 3 checkbuttons in the Options menu in any combinations and test if crash happens again.
These are various options that change the drawing methods /fix some inconsistencies seen ot buggy servers.

• No XCopyArea drawing model
• Fix for GPUs with broken tiled fill
• Fix broken RDP mouse coordinates
  

[StefanSchippers]

One test you should do is to go in the Xserver configuration and if possible disable Hardware acceleration for it. OpenGL (or the WIndows equivalent) and hardware acceleration is in general the mother of all graphical problems.
Going deeper try also to disable hardware acceleration in the Virtual machine engine. This also fixed some VM related crashes in the past.

[StefanSchippers]

Do we already have some kind of error log? Or is this always lost due to the whole X-Server crashing?

It is possible to start xschem in debug mode and save all messages to a log file:
xschem -d 1 - l logfile
You can also increase the debug level (-d 2 or -d 3) but I don't recommend to do that in the first place as it produces a shitton of information.

[simi1505]

I now tried out the three checkbuttons but it still crashes after some time. Most of the time it crashes during scrolling with the mouse wheel. Can this be a hint for something?

[simi1505]

One test you should do is to go in the Xserver configuration and if possible disable Hardware acceleration for it.

Is there a config file somewhere for this? Right now I can only configure one checkbox during the start of the X-Server:

However, I could enter an additional parameter for VcXsrv. Should I try something here? Any suggestions?

[simi1505]

It is possible to start xschem in debug mode and save all messages to a log file:
xschem -d 1 - l logfile

I have tried this now. Where can I find the logfile? It is not located in the folder where I executed Xschem and also not in the installation folder foss/tools/xschem/....

[StefanSchippers]

I can only configure one checkbox during the start of the X-Server:

Have you tried disabling it?
Also try to see if there is a similar option do disable Acceleration on the Virtual machine.

[StefanSchippers]

It is possible to start xschem in debug mode and save all messages to a log file:
xschem -d 1 - l logfile

I have tried this now. Where can I find the logfile? It is not located in the folder where I executed Xschem and also not in the installation folder foss/tools/xschem/....

the log file is in the directory where xschem is started.
If the file is not there may be the directory is not writeable.

If opening the log file fails for whatever reason xschem will fall back using the default stderr stream.

output.mp4

[MrHighVoltage]

Okay, I setup a Windows-Workstation with the tools now and I can reproduce this error.
It crashes with OpenGL enabled or disabled, that's not it. Further, I can get it to crash pretty quickly by zooming and scrolling around in Xschem, so it looks more like a race-condition and less like some kind of timeout.
Suddenly, everything stops and crashes, including the X-Server (VcXsrv in this case, which surprises me a bit).

The Logfile does not include any errors, I'm afraid Xschem crashes before it can write the last errors.

[StefanSchippers]

Can you please try to zoom in/out with ctrl-z / Shift-Z ? does it crash too?

[MrHighVoltage]

I got some log-infos out of the X-Server, first it spams the following line a few hundret times:

winCreateDIB: CreateDIBSection() failed

followed by

winBltExposedWindowRegionShadowGDI - BitBlt failed: 0x00000006
winBltExposedWindowRegionShadowGDI - BitBlt failed: 0x00000006
winCreateDIB: CreateDIBSection() failed

Then the log file ends.

Can you please try to zoom in/out with ctrl-z / Shift-Z ? does it crash too?

Yes, it does too. repeatedly clicking fast without waiting for the previous action to finish, seems to do the trick.

[StefanSchippers]

Also this link contains some information about setting up VcXsrv in windows WSL2, may be it contains some useful info:
https://jack.kawell.us/posts/ros-windows-wsl2/

also some other info I found lurking into the web:

 To make VcXsrv work with WSL 2, you need to add the following two lines in your .bashrc file:

export LIBGL_ALWAYS_INDIRECT=1

Although I don't think this affects xschem as it does not use 3D acceleration.

[StefanSchippers]

Another easy test is to disable the grid in an empty xschem window (Options --> Draw grid) and try to scroll / zoom.
Does it crash still? in this case xschem has really nothing to draw, so it adds a bit of information to the picture.

[MrHighVoltage]

On an empty, grid only, or very simple schematic, it doesn't crash, no matter how fast I zoom/move etc...

[simi1505]

On an empty Xschem window with or without a grid, it does not crash. If I add only a symbol it crashes shortly after scrolling.

[StefanSchippers]

Ok, thank you.

The next step is to try a build of xschem without cairo.
Cairo is the library to render nice character fonts in xschem. Without it xschem displays (quite ugly) vector fonts instead, not using the whole cairo system at all.

To do that edit config.h in the top source directory of xschem and comment out (do not set it to 0!) this line:
/* #define HAS_CAIRO 1 */
Then rebuild and install xschem.

With Cairo:

Without Cairo:

[MrHighVoltage]

okay, 3.4.4, like you initially suggested, also crashes the same way.

[StefanSchippers]

Thank you, so this is not related to any recent change / addition in xschem since 3.4.4 was tagged in Oct 2023.

commit 6305b52d91bf0c73ea0d65ba9797b4f44d5ff100 (tag: 3.4.4)
Author: stefan schippers <[email protected]>
Date:   Mon Oct 9 13:53:57 2023 +0200

[MrHighVoltage]

To do that edit config.h in the top source directory of xschem and comment out (do not set it to 0!) this line:
/* #define HAS_CAIRO 1 */
Then rebuild and install xschem.

Isn't that already disabled?

[StefanSchippers]

To do that edit config.h in the top source directory of xschem and comment out (do not set it to 0!) this line:
/* #define HAS_CAIRO 1 */
Then rebuild and install xschem.

Isn't that already disabled?

If your config.h has this line already commented, then yes, it is disabled (configure did not find the needed cairo headers and disabled it already). If so it isn't cairo either causing the crash...

[StefanSchippers]

Also I see lot of posts about VcXsrv crashes, so it should be nice to test the Cygwin (XWin.exe) Xserver. I used this server 15 years ago on windows 7, and for these pieces of software older is better in general.
https://a.fsdn.com/con/app/proj/xschem/screenshots/xschem_on_windows.png/max/max/1

[MrHighVoltage]

I think @simi1505 already tried it with Xming. Is that correct?

[StefanSchippers]

I strongly suggest to go for the real thing.
https://x.cygwin.com/
This provides (among a complete Posix layer on windows) the Cygwin X server (Cygwin/X).
Al these toy projects like Xming / VcXsrv are doing nothing but adding additional bugs.

Also I see that :
WSLg (Windows Subsystem for Linux GUI) is an extension of WSL 2 that allows you to run Linux GUI (Graphical User Interface) applications directly on Windows 10 and 11, without the need for a third-party X Server like VcXsrv and any additional configurations.
https://github.com/microsoft/wslg
If this is available I should definitely go that way to reduce dependencies and get rid of any external X server.

[StefanSchippers]

For the time being I see lot of open tickets (Some very old ones) related to the server crash.

In general an Xserver should not crash if applications do bad things with it. It should report errors like BadAlloc, BadMatch, BadRequest, BadValue, BadDrawable and so on... and may be the application should terminate or crash.

[MrHighVoltage]

I also tried Cygwin/X now, same crash behavior, but I get more meaningful log outputs and it segfaults after the same messages as VcXsrv:

winCreateDIB: CreateDIBSection() failed
winBltExposedWindowRegionShadowGDI - BitBlt failed: 0x00000006
winBltExposedWindowRegionShadowGDI - BitBlt failed: 0x00000006
winCreateDIB: CreateDIBSection() failed
(EE) Fatal signal received in thread 0xa00000010 [0x3108]
(EE) Segmentation fault at address 0x0
(EE) Install gdb to get reasonable backtraces
(EE) /usr/bin/xorg-backtrace failed with returncode 2
(EE) Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE) Server terminated with error (1). Closing log file.
winDeinitMultiWindowWM - Noting shutdown in progress
Aborted

Anyways, we could not reproduce this error on Linux or MacOS (with XQuartz), only on Windows. The most promising solution right now seems to be WSLg, also because of reduced installation/maintance effort. But we do have rework the start scripts and documentation and we are currently held up with other important tasks.

So for now, we keep it that way. It seems to only be an issue on huge XSchem-Schematics on Windows with X11 mode. If more reports of this error show up, we might revert to the last container release until this error is properly fixed.

Thanks for your help, so far!

[StefanSchippers]

As far as I can tell both Xservers fail when trying to create a DIB (Device independent Bitmap). These are areas where the Xserver draws into, the area is then handed over for displaying.

Try to find settings in the WSL2 / Xserver about reserved Video memory and if you find anything increase the limit.
Try also to run a xschem instance, make the xschem window small and load a big schematic.
Does it still crash the server?

[StefanSchippers]

Also try to see if the docker container is not enforcing some limits. (although xschem is really a small application)

[StefanSchippers]

Can you also try to run xschem out of the container? I mean clone the repo, build and install, then execute outside of any container.