Hi Werner,
Yes you are correct, not just fdesign but also many applications and even
quite old copies of the xforms library are impacted.
Technically the library should not pass a NULL pointer to the libX11
XStoreName function. However historically XStoreName has coped if you do.
This has been broken in the more recent libX11.
Note, from the man page
int XStoreName(Display *display, Window w, char *window_name);
window_name: Specifies the window name, which should be a null-terminated
string.
The best solution would be to make sure xforms doesn't pass a NULL pointer.
I'm on an old version, else I'd generate the patch. Maybe someone working on
the current version can sort it out.
In my old version the call is in xpopup.c, basically you need to change
XStoreName(flx->display, m->win, m->title);
to
XStoreName(flx->display, m->win, m->title ? m->title : "");
Or something like that.
Interesting, I was assured the fix would be coming through from upstream. But
either way, better we fix it.
Cheers
Clive
On Sat, 31 Jul 2021, Werner Heisch wrote:
Hi Clive, hi Coby, Hi all,
I've had the same problem on Opensuse Leap 15.2.
BTW: not only fdesign is affected, also applications which use
a 'menu' or a 'choice'.
I reported the problem to Suse at May 30th, and it had been solved very
quickly.
This link contains all necessary informations:
https://bugzilla.suse.com/show_bug.cgi?id=1186643
Here included is the solution:
https://gitlab.freedesktop.org/xorg/lib/libx11/-/commit/ab2f59530b16bdfbf023b8e025c7c8aba3b6fd0c
I assumed it would be automaticly part of the X11-updates, but
unfortunately it seems to be not:
Today, End of July, 2 month ago,
I found the faulty behaviour after the updates of following OSes:
Debian 9.x and Debian10.10 ( the actual version)
Because Raspberry OS bases on Debian, also Raspberry implementations
are crashing after an update.
This problem is in the xlib.
As long we will not update our OS, all will be ok, but that
will not be the right way.
(In my case, industrial production will be involved. )
I have no clue about X11 and cannot decide if there is a fault in
Xforms.
But I think, if an application ( fdesign, other xforms-based
applications ) is working for some decades it should not crach because
of a change of a library .. especially if it is quite easy to recorrect
this problem on the library side.
If you know about an os which still has not a correcting update,
please inform the maintainers to correct this.
<<<<<<<<<<<<<<<<<<<<<<<<
Of course, also solving this problem on our ( -> xforms) side would
be better. Therefore:
QUESTION: ( To people who know X11 )
Do we have a fault in the forms library or is there an other solution
to get rid of this problem for future implementations or by updating
the forms library ?
Thank You,
Werner Heisch
Am Wed, 30 Jun 2021 02:27:35 +0100 (BST)
schrieb Clive Stubbings <cas12@vjet.f2s.com>:
Hi,
There has been a regression in the xorg libX11
It is likely this is your issue - it was spotted in one of my xforms
programs a few weeks ago by one of my users.
XStoreName used to tolerate a NULL pointer (it checked before using
it). New code has been added ahead of that check.
If your system has recently updated its libraries, thats likely the
cause.
I believe it has now been fixed upstream thanks to the person who
spotted the problem feeding the cause back to the developers and a
new version should come through in due course.
If you need a quicker fix, hack the library to make sure it doesn't
pass a NULL pointer to XStoreName.
Cheers
Clive
On Sun, 27 Jun 2021, ternaryd wrote:
On Sat, 26 Jun 2021 15:47:12 -0700
Coby Hochstein <cjh39@cox.net> wrote:
Hello,
when I load fdesign and click on the "File"
menu bar fdesign segmentation faults.
I'm running xforms-1.2.4
(gdb) run
Starting program: /usr/local/bin/fdesign
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/arm-linux-gnueabihf/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation
fault.
strlen () at ../sysdeps/arm/armv6/strlen.S:26
26 ../sysdeps/arm/armv6/strlen.S: No such
file or directory.
(gdb)
Any idea ?
fdesign is calculating the string length of a
string pointing to NULL.
Use a version of fdesign compiled with debugging
enabled, run it again until crash, and check the
coredump in gdb. Use the "up" command until you
reach a stack level belonging to fdesign (or
xforms). You should see which pointer is NULL.
Then you can try to figure out, why it is NULL
and how to fix it.
$ ulimit -c unlimited
$ ./fdesign ...
$ gdb ./fdesign coredump
(gdb> up
...
you can query the value of any variable at the
time of the crash with
(gdb) p varname
HTH
--
Cris