#67280 closed defect (worksforme)

gtk3: Crash when typing text with gtk3 on ARM mac

Reported by: Akkiesoft (Akira Ouchi) Owned by: mascguy (Christopher Nielsen)
Priority: Normal Milestone:
Component: ports Version: 2.8.1
Keywords: Cc: dbevans (David B. Evans)
Port: gtk3

Description

On M1 Mac mini and Ventura 13.3.1, when I start a gtk3 application and type text in the Entry widget, the application crashes.

I tested with ruby-gnome, pygtk and C code.

I don't think it is a specific language issue, as all of the codes produce the same output on crash.

% ./gtk-test 
dbus[16476]: Dynamic session lookup supported but failed: launchd did not provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!

(gtk-test:16476): Gdk-ERROR **: 23:04:56.893: The program 'gtk-test' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadLength (poly request too large or internal Xlib length erro'.
  (Details: serial 287 error_code 16 request_code 72 (core protocol) minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
zsh: trace trap  ./gtk-test
% python3 pygtk-entry-test.py
dbus[16448]: Dynamic session lookup supported but failed: launchd did not provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!

(gtk_test.py:16448): Gdk-ERROR **: 23:03:09.973: The program 'gtk_test.py' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadLength (poly request too large or internal Xlib length erro'.
  (Details: serial 287 error_code 16 request_code 72 (core protocol) minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
zsh: trace trap  python3 pygtk-entry-test.py
% ruby ruby-gnome-entry-test.rb
dbus[16425]: Dynamic session lookup supported but failed: launchd did not provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!

(bb.rb:16425): Gdk-ERROR **: 23:00:33.553: The program 'bb.rb' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadLength (poly request too large or internal Xlib length erro'.
  (Details: serial 283 error_code 16 request_code 72 (core protocol) minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
zsh: trace trap  ruby ruby-gnome-entry-test.rb

Only Python showed mac OS report screen on crash.

https://gist.github.com/Akkiesoft/8a1acd6dcb5af4b2812ff6849a7f634b

I am using XQuartz 2.8.5 and have tried 2.8.6 beta1 but cannot solve the problem.

Attachments (4)

gtk-entry-test.c (521 bytes) - added by Akkiesoft (Akira Ouchi) 19 months ago.
pygtk-entry-test.py (190 bytes) - added by Akkiesoft (Akira Ouchi) 19 months ago.
ruby-gnome-entry-test.rb (158 bytes) - added by Akkiesoft (Akira Ouchi) 19 months ago.
pygtk3-crash.log (117.3 KB) - added by Akkiesoft (Akira Ouchi) 19 months ago.

Download all attachments as: .zip

Change History (15)

Changed 19 months ago by Akkiesoft (Akira Ouchi)

Attachment: gtk-entry-test.c added

Changed 19 months ago by Akkiesoft (Akira Ouchi)

Attachment: pygtk-entry-test.py added

Changed 19 months ago by Akkiesoft (Akira Ouchi)

Attachment: ruby-gnome-entry-test.rb added

Changed 19 months ago by Akkiesoft (Akira Ouchi)

Attachment: pygtk3-crash.log added

comment:1 Changed 19 months ago by Akkiesoft (Akira Ouchi)

type text in the Entry widget, the application crashes.

However, strings could be pasted from the clipboard.

comment:2 Changed 19 months ago by mascguy (Christopher Nielsen)

Cc: dbevans added
Owner: set to mascguy
Status: newassigned
Version: 2.8.1

comment:3 in reply to:  description ; Changed 19 months ago by ryandesign (Ryan Carsten Schmidt)

Replying to Akkiesoft:

verify that org.freedesktop.dbus-session.plist is loaded!

You should do this, however I don't know how. I thought the dbus port would take care of it automatically assuming you have done what is printed when you run port notes dbus.

comment:4 in reply to:  3 Changed 19 months ago by Akkiesoft (Akira Ouchi)

Hi.

Replying to ryandesign:

Replying to Akkiesoft:

verify that org.freedesktop.dbus-session.plist is loaded!

You should do this, however I don't know how. I thought the dbus port would take care of it automatically assuming you have done what is printed when you run port notes dbus.

% port notes dbus
--->  dbus has the following notes:
  Startup items (named 'dbus-system, dbus-session') have been generated that
  will aid in starting dbus with launchd. They are disabled by default. Execute
  the following command to start them, and to cause them to launch at startup:
  
      sudo port load dbus

So I ran this command and restarted my Mac.

After rebooting, the dbus message no longer appears, but test programs still seems to crash.

% ./gtk-test

(gtk-test:6129): Gdk-ERROR **: 10:55:38.720: The program 'gtk-test' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadLength (poly request too large or internal Xlib length erro'.
  (Details: serial 317 error_code 16 request_code 72 (core protocol) minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
zsh: trace trap  ./gtk-test

comment:5 Changed 19 months ago by mascguy (Christopher Nielsen)

Can you paste the output from port installed gtk3?

comment:6 in reply to:  5 Changed 19 months ago by Akkiesoft (Akira Ouchi)

Replying to mascguy:

Can you paste the output from port installed gtk3?

% port installed gtk3
The following ports are currently installed:
  gtk3 @3.24.34_2+x11 (active)

comment:7 Changed 19 months ago by mascguy (Christopher Nielsen)

We're currently testing a new release of gtk3, which might have a fix for this issue. (Though I haven't checked upstream's changelog, so difficult to say.)

But if you want to try it - and that might be worthwhile, to see whether it's still an issue with the new release - do the following:

$ sudo port -f deactivate gtk3
$ sudo port -N install gtk3-devel

Then rereun your apps/utils, to see whether it's still an issue.

comment:8 in reply to:  7 ; Changed 19 months ago by Akkiesoft (Akira Ouchi)

Replying to mascguy:

We're currently testing a new release of gtk3, which might have a fix for this issue. (Though I haven't checked upstream's changelog, so difficult to say.)

But if you want to try it - and that might be worthwhile, to see whether it's still an issue with the new release - do the following:

$ sudo port -f deactivate gtk3
$ sudo port -N install gtk3-devel

Then rereun your apps/utils, to see whether it's still an issue.

Thank you.

I installed gtk3-devel but the application still crashes.

comment:9 in reply to:  8 Changed 19 months ago by mascguy (Christopher Nielsen)

Replying to Akkiesoft:

I installed gtk3-devel but the application still crashes.

While I don't have an ARM machine to test on, I'm in the process of setting up a macOS 13.x VM. Once that's done, I'll see if I can reproduce there. I'll also check the upstream issues, to see if there's a pending fix.

Stay tuned...

comment:10 Changed 19 months ago by Akkiesoft (Akira Ouchi)

I found the cause. An option I added to work around an M1 Mac-specific bug in XQuartz was causing problems.

https://github.com/XQuartz/XQuartz/issues/31#issuecomment-1301392914

% defaults write org.xquartz.X11 enable_render_extension 0

Removing the option avoids the crash, but it is very annoying because the Xquartz bug where the background turns black will reappear... :(

% defaults delete org.xquartz.X11 enable_render_extension

Anyway, it was not a gtk3 problem. Sorry for the disturbance.

comment:11 in reply to:  10 Changed 19 months ago by mascguy (Christopher Nielsen)

Resolution: worksforme
Status: assignedclosed

Replying to Akkiesoft:

I found the cause. An option I added to work around an M1 Mac-specific bug in XQuartz was causing problems.

https://github.com/XQuartz/XQuartz/issues/31#issuecomment-1301392914

% defaults write org.xquartz.X11 enable_render_extension 0

Removing the option avoids the crash, but it is very annoying because the Xquartz bug where the background turns black will reappear... :(

% defaults delete org.xquartz.X11 enable_render_extension

Anyway, it was not a gtk3 problem. Sorry for the disturbance.

No worries, glad the issue is resolved!

Note: See TracTickets for help on using tickets.