#54 window does not always close by the exit entry in the file menu

[sgerwk]

When clicking on 'exit' in the file menu, the program terminates but the window sometimes remain open (and irresponsive, of course). Whether it does seems to depend on which other programs are running at the same time: with just xfig+xterm, the window remains open. With opera or luakit, it does not.

meta-q always works.

The attached patch seems to fix the bug.

[tkl]

Could you confirm, that there is not a pop-up window, well, not popped up but hidden behind the window? If a figure is modified within xfig and not yet saved, on pressing File -> Exit a window pops up, "The current figure is modified. Do you want to save it before quitting?" That window may be hidden behind the main window.

When the XSync() command is inserted in w_cmdpanel.c, what happens here in a gnome-environment is:
Starting xfig from the command line, pressing File -> Exit, the following error
message is displayed:

xfig3.2.7a-dev: X error trapped - error message follows:
BadFont (invalid Font parameter)
Request code: X_CloseFont
xfig: Figure is empty or not modified - exiting without saving.
free(): double free detected in tcache 2
Aborted (core dumped)

Secondly, starting xfig from the command line, drawing a box, pressing File ->
Exit, in the pop-up window "The current figure is modified..." choosing "No":

xfig3.2.7a-dev: X error trapped - error message follows:
BadFont (invalid Font parameter)
Request code: X_CloseFont
xfig: attempting to save figure
xfig: 1 object(s) saved in "/tmp/xfig/src/SAVE.fig"
free(): double free detected in tcache 2
Aborted (core dumped)

It may well be that the X-server here, which I believe is really an interface offered by wayland, behaves differently than your X-server. Without further testing I am hesitant to apply the patch.

[sgerwk]

Could you confirm, that there is not a pop-up window, well, not popped up but
hidden behind the window? If a figure is modified within xfig and not yet
saved, on pressing File -> Exit a window pops up, "The current figure is
modified. Do you want to save it before quitting?" That window may be hidden
behind the main window.

Hi, thanks for checking this.

Iconifying the xfig window, the menu remains on screen but there is no
confirmation window around. Also, the xfig program already terminated at this
point (I run it from an xterm without '&', and it returned to the shell). I
didn't draw anything in xfig, just started it, pressed File and then Exit.

Yesterday I forgot to mention a couple of things:

• the window and menu close when I start another X Window program, such as
  "xterm" or "xwininfo -root"

• I was running in powersave Linux mode:
  echo powersave >| /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
  this is a mode of operation where the cpu constantly runs at the lowest
  possible frequency; in conservative mode, the window closes on exit; to me,
  this means that the problem is related to timings

When the XSync() command is inserted in w_cmdpanel.c, what happens here in a gnome-environment is:
Starting xfig from the command line, pressing File -> Exit, the following error
message is displayed:
~~~text
xfig3.2.7a-dev: X error trapped - error message follows:
BadFont (invalid Font parameter)
Request code: X_CloseFont
xfig: Figure is empty or not modified - exiting without saving.
free(): double free detected in tcache 2
Aborted (core dumped)
~~~

Secondly, starting xfig from the command line, drawing a box, pressing File ->
Exit, in the pop-up window "The current figure is modified..." choosing "No":
~~~text
xfig3.2.7a-dev: X error trapped - error message follows:
BadFont (invalid Font parameter)
Request code: X_CloseFont
xfig: attempting to save figure
xfig: 1 object(s) saved in "/tmp/xfig/src/SAVE.fig"
free(): double free detected in tcache 2
Aborted (core dumped)
~~~
It may well be that the X-server here, which I believe is really an interface offered by wayland, behaves differently than your X-server. Without further testing I am hesitant to apply the patch.

I didn't get any of this while running in:

• fvwm
• twm
• irwm (my window manager, I grant it's not much tested)
• no window manager:
  { sleep 5; xterm -display :0 ; } & /usr/lib/xorg/Xorg -nolisten tcp -retro :0
  vt1 -keeptty

In all this modes, the xfig window doesn't close without the patch. My X Server
is:

X.Org X Server 1.19.2
Release Date: 2017-03-02
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.9.0-8-amd64 i686 Debian
Current Operating System: Linux sgerwk 4.15.5-1 #2 PREEMPT Fri Jun 29 18:21:27 CEST 2018 i686
Kernel command line: radeon.modeset=0 video=640x400 shelldelay=0 initrd=initrd-4.15.5-1-mmr BOOT_IMAGE=vmlinuz-4.15.5-1
Build Date: 03 November 2018 03:08:43AM
xorg-server 2:1.19.2-1+deb9u5 (https://www.debian.org/support)
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.

I'd like to test the problem with the same configuration you have. How did you
start X with the gnome-environment?

[sgerwk]

Also: the window closes even if XSync() is replaced by sleep(2) (of course
that's not a viable solution since termination is delayes by two seconds). Do
you get the same errors with this change?

[tkl]

Iconifying the xfig window, the menu remains on screen…

The menu can be provoked to stay on the screen by opening it from the keybord by pressing <alt>-f, then minimizing the main xfig-window with the mouse pointer. I missed such behavior because I mainly operate with the mouse cursor. Just a cursory observation, that the keyboard accelerators may need some care.</alt>

the window and menu close when I start another X Window program, such as
"xterm" or "xwininfo -root"

You mean, xfig should stay open, but it vanishes under your eyes when doing something unrelated?

I had a look now, and have to admit that my machine does not have a native X-server, only wayland. I will have to download a native X server. The system here is archlinux, the .profile file contains the line XDG_SESSION_TYPE=wayland dbus-run-session gnome-session . pacman -Qs xorg-server outputs: xorg-server-common 1.20.4-1, xorg-server-xwayland 1.20.4-1. Regarding starting the session, see also the entry in the archlinux wiki on Gnome.

I am afraid, this issue will need some serious debugging and backtraces.

[sgerwk]

You mean, xfig should stay open, but it vanishes under your eyes when doing something unrelated?

No, I was still talking about the situation after I click on file, then exit. The window is still open, but it shouldn't. In this particular situation, "xwininfo -root" causes it it to close.

This happens on debian. I will test the problem and the patch under archlinux.

[tkl]

Thanks a lot for investigating the issue!
To answer a question I first overlooked: sleep(2) does not cause any harm.
The backtrace after exiting from xfig, with the XSync(..) line inserted indeed indicate a race condition: goodbye() is called twice, first by the user, then by the installed X_error_handler() .
Moving XSync(tool_d, False) a few lines up above the free_GCs() line does help: xfig exits properly, without an error. This was tested both under gnome-session with xorg-server-xwayland and under mwm, with xorg-server 1.20.4-1.

[sgerwk]

With XSync(tool_d, False) above free_GC() the xfig window closes properly every time now. Thanks!

[sgerwk]

This is in part a related issue: free_Fonts() in u_free.c unloads fonts using nf->fid, but I do not see where this field is set.

I tried to add canary values to every struct xfont right after every malloc(sizeof(struct xfont)), and it seems that they are still there when the fonts are freed by free_Fonts(); see attached file.

Perhaps nf->fid is not needed after all, and one may rather use nf->fstruct->fid if nf->fstruct is not NULL?

This is related to the ticket because I believe the error is not normally shown because xfig terminates before the arrival of the answer from the X server telling that the font is invalid.

[tkl]

I believe, line 270 in u_free.c, XUnloadFont(tool_d, nf->fid);, should be commented out. I also did not find a place where nf->fid is set. After commenting out that line, do you experience any issues?

[sgerwk]

No problem with commenting out XUnloadFont(): I have tested it in the original xfig version, the one with XSync and the one with a modified main loop, an none showed any error. The original version still does not close in powersave mode, as expected.

According to XCloseDisplay(3), the fonts are unloaded anyway on close (when no other program uses them) unless specified otherwise by XSetCloseDownMode(3), but this seems not to be called anywhere in xfig.

[tkl]

Fixed with release 3.2.7b.