Message Boards Message Boards

GROUPS:

Avoid Mathematica 11.2.0 Front End crashes when run via Xtightvnc?

Posted 8 months ago
802 Views
|
1 Reply
|
4 Total Likes
|

Workaround: Don't use Mma 11.2.0 w/ Xtightvnc; use it native, or via ssh -X or xrdp using Xorg on up-to-date (stretch) Raspbian installations.

I recently upgraded a Raspberry Pi 2 and Raspberry Pi 3 (both kept up-to-date, and running stretch), and the new wolfram-engine got updated to 11.2.0+2018011502 armhf.

Mma 11.2.0 does work (only checked on the RPi 3) on the native display, and via ssh -X from a (up to date) CentOS 7, and via xrdp using Xorg as the server on RPi 2 -- it's just the Xtightvnc version on the RPi that fails. That's xtightvncviewer 1:1.3.9-9 armhf.

The problem manifests as a silent windows-go-away after startup, triggered by mouse-overs on the small window with the icons (or attempted data entry in the notebook).

By attaching gdb to the front end right after startup but before mouse overs, I discovered the following failure on subsequent mouse overs; note that where it died is a bit of a red herring, since the memory state has already been damaged -- the stack is reported as corrupt.

(gdb) catch signal
Catchpoint 1 (standard signals)
(gdb) cont
Continuing.
[Thread 0x6e1762e0 (LWP 18285) exited]
[Thread 0x6f48a2e0 (LWP 18281) exited]
[Switching to Thread 0x6ffff2e0 (LWP 18280)]

Thread 7 "Qt bearer threa" hit Catchpoint 1 (signal SIGSEGV), 0x75853c68
    in QNetworkConfigurationManagerPrivate::pollEngines() ()
    from /opt/Wolfram/WolframEngine/11.2/SystemFiles/Libraries/Linux-ARM/libQt5NetworkWRI.so.5
(gdb) where
#0  0x75853c68 in QNetworkConfigurationManagerPrivate::pollEngines() ()
from /opt/Wolfram/WolframEngine/11.2/SystemFiles/Libraries/Linux-ARM/libQt5NetworkWRI.so.5
#1  0x758e9194 in ?? () from /opt/Wolfram/WolframEngine/11.2/SystemFiles/Libraries/Linux-ARM/libQt5NetworkWRI.so.5
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

​ I'm pretty sure Mathematica provided with wolfram-engine 11.0.1+2017071100 used to work over vnc using Xtightvnc -- it no longer does, on either the RPi 2 or RPi 3. Non-GUI "wolfram" is fine.

​So it very much looks like the new version of wolfram-engine, 11.2.0, released for Raspberry Pi's has a problem with certain (less capable) X servers, specifically Xtightvnc.

FYI, the Xtightvnc server has limited extensions, and lacks GLX etc. Here's some xdpyinfo from Xtightnvc.

$ xdpyinfo
name of display:    :3.0
version number:    11.0
vendor string:    AT&T Laboratories Cambridge
vendor release number:    3332
maximum request size:  4194300 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    2
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 255
focus:  window 0x4000030, revert to Parent
number of extensions:    7
    BIG-REQUESTS
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    SHAPE
    SYNC
    XC-MISC
    XTEST
default screen number:    0
number of screens:    1

I hope you find this useful.

Thanks for the useful and detailed report, it's been passed to the developers/QA team.

Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract