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.

[StefanSchippers]

@hpretl are there updates on this nasty crash? Just curious if there is something I can investigate on my side (although i don't have windows machines to test on) or if the problem was addressed somewhere else.
Thank you

[hpretl]

No further action on our side meanwhile (busy on other stuff). Could this here have something to do with it: StefanSchippers/xschem@60d180d

[StefanSchippers]

I don't think the fix above is related to a X server crash, but who knows.
This was a nasty xschem bug leading to writes in unallocated memory, so anything can happen. But usually should not crash the X server (that is an external process). Anyway please check you don't have one of the indicated ranges of commits affected by the bug in a docker image.

[hpretl]

@simi1505 I have made a build with the latest Xschem, Docker image tag next. Could you please test this release whether the crash you see is still there?

[simi1505]

Unfortunately, it is still crashing.

[StefanSchippers]

@simi1505 @hpretl One thing I do in these cases to debug graphic issues is to run a desktop (or better, just a window manager) in a VNC server on a different linux host on the same local network, set the DISPLAY variable to point to the VNC server and run xschem.

in 100% of the cases I have dealt with so far all graphic glitches, garbage on screen, screen redraw issues, event handling, crashes related to graphic operations, errors due to off-spec graphic primitives go away (Nvidia, are you hearing me?).

This does not resolve the problem, but hopefully gives some more information.

It is also possible to directly connect to another X server but modern Linux boxes by default do not accept network connections and you probably need to reconfigure and restart the server and this is a super boring task (and also a temporary security hole).

[EngGhaith]

I had that problem, but after I have uninstalled the Xsrv and its data, then I have downloaded the latest version it works again without any crash!

[StefanSchippers]

I had that problem, but after I have uninstalled the Xsrv and its data, then I have downloaded the latest version it works again without any crash!

@MrHighVoltage @simi1505 @hpretl

[hpretl]

@EngGhaith Interesting find! @simi1505 Could you please try this on your computer as well? If it works, I will add it to the KNOWN_ISSUES.md.

[ihagg]

Hi everyone, I found a wide variety of problems among my students with both VcXsrv and Xming servers on Windows 11. We decided to switch to MobaXterm (Home Edition, portable) and it turned out to be a stable solution for all students. I hope this feedback helps.

[hpretl]

@ihagg Thanks for the info! @simi1505 Could you please try this suggestion and see whether it works for you?

[simi1505]

Hi everyone!

I re-installed VcXsrv and also tried MobaXterm, but unfortunately, it is still crashing. With the DOCKER_TAG=2024.12 Xschem is in general much smoother.

Did you all use DOCKER_TAG=next?

Anyway, thanks for the support!

[IlirShala1]

Hi,

I have tested two versions of VcXsrv. The newest one, Version: 64.1.20.14.0 (website: https://sourceforge.net/projects/vcxsrv/, doesn’t work for me (crash). However, version 64.1.17.2.0 (website: https://vcxsrv.com/) works very well for me. I worked in xschem for more than half hour and there were no crashes. @simi1505 Can you check this as well?

[simi1505]

Interestingly, version 64.1.17.2.0 (website: https://vcxsrv.com/) works with DOCKER_TAG=next!

I will also try the latest version now. Thanks!

Edit: DOCKER_TAG=latest also works fine with version 64.1.17.2.0. At least for some minutes. But it feels much smoother now. So, I think this problem is solved. Yes!

Thanks again, everyone.

[hpretl]

Findings added to KNOWN_ISSUES.md with be1d0a7.

[MrHighVoltage]

As this is still an ongoing issue, I prepared the work to switch to WSLg as recommended by @StefanSchippers . Some tests showed very promising performance and no crashes. Also the setup gets significantly easier, as no third-party X-Server is used any more.

The (currently untested) script is already pushed to next_release, I will test it in the evening. If you have time to test it, there is no need to update the container, but the repository with the new script should be downloaded!

[simi1505]

I downloaded the IIC-OSIC-TOOLS repo, changed DOCKER_TAG=next and updated the image in the Docker (3 days old). If I understand correctly, I do not need the X-Server anymore. So, if I start the container in the Docker App without running X-Server, a command line should start right? This is not the case. What else do I need to do? Thanks!

[MrHighVoltage]

You have to download the "next_release" branch of the Repo, the container itself should be fine for now (although, there will be some updates, so stay on "next" here for now).

I already tested it and pushed some more modifications. A rebuild of the container will be required, but most of the tools should already work out of the box!

[MrHighVoltage]

So far, everything, that doesn't require GPU acceleration, works fine and is really quick and seemingly stable.

Although there might be some work to do on GPU acceleration, as the approach on WSLg is the forwarding of a "virtual GPU" that is based on the hosts GPU. For that, it basically forwards the commands to the physical GPU. And as of right now, this is not working and requires some work.