You will get the same behaviour using the cairo fix too:
https://bugs.freedesktop.org/show_bug.cgi?id=98883#c6
** Changed in: cairo (Ubuntu)
Importance: Undecided => High
** Changed in: cairo (Ubuntu Bionic)
Importance: Undecided => High
** No longer affects: glib2.0 (Ubuntu)
** No
I tried the patch for /usr/lib/ubiquity/ubiquity/misc.py in a virtual
machine.
Instead of corrupted graphics in the Ubiquity window, I saw a blank
white area above the "Copying files..." progress bar.
After a few seconds, the Ubiquity slide show appeared as usual, and I
did *not* get a crash.
I
Fix for ubiquity proposed here:
https://code.launchpad.net/~azzar1/ubiquity/+git/ubiquity/+merge/345056
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1751252
Title:
[regression]
** Changed in: cairo
Status: Unknown => Confirmed
** Changed in: cairo
Importance: Unknown => Medium
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1751252
Title:
A patch to fix the crash is here:
https://bugs.freedesktop.org/show_bug.cgi?id=98883#c6
If we fail to get cairo fixed for any reason, it's probably possible to
do a workaround/fix in ubiquity. But I think there are now multiple
reasons to fix cairo as first preference.
** Bug watch added:
** Also affects: cairo (Ubuntu)
Importance: Undecided
Status: New
** Changed in: cairo (Ubuntu)
Assignee: (unassigned) => Daniel van Vugt (vanvugt)
** Changed in: cairo (Ubuntu)
Status: New => In Progress
** Changed in: cairo (Ubuntu Bionic)
Status: New => In
Please report crash files by running this command:
ubuntu-bug YOURFILE.crash
Attaching them to bugs is not helpful to us, and a security risk to you.
** Attachment removed: "_usr_lib_ubiquity_bin_ubiquity.0.crash"
I can reproduce this issue on xps13 9350. crash report is attached.
** Attachment added: "_usr_lib_ubiquity_bin_ubiquity.0.crash"
https://bugs.launchpad.net/oem-priority/+bug/1751252/+attachment/5132791/+files/_usr_lib_ubiquity_bin_ubiquity.0.crash
--
You received this bug notification
** Changed in: ubiquity (Ubuntu)
Assignee: (unassigned) => Daniel van Vugt (vanvugt)
** Changed in: ubiquity (Ubuntu Bionic)
Assignee: (unassigned) => Daniel van Vugt (vanvugt)
** Changed in: ubiquity (Ubuntu)
Status: Triaged => In Progress
** Changed in: ubiquity (Ubuntu
Ubiquity also crashes inside a virtual machine (VirtualBox) running on a
non-HiDPI host machine.
I have observed corrupted graphics in the "main area" of Ubiquity when
this bug occurs. By "main area", I am referring to the rendered
rectangular area in Ubiquity below the title bar and above the
OK, I can now reproduce the problem at scale=100%. The trick is to slow
down the installer with GDK_SYNCHRONIZE=1. So this is just a race
condition, usually triggered by slower rendering of scale 200%, but can
be triggered other ways.
--
You received this bug notification because you are a
So it sounds like a race between Xorg and the ubiquity perms dropping
which then breaks Xorg's ability to authenticate XShmAttach used in
cairo.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to glib2.0 in Ubuntu.
Unfortunately I can't tell what in shm_access is failing exactly because
gdb skips straight from shm.c:314 back to the caller. So that suggests
this code path, but I can't verify it:
static int
shm_access(ClientPtr client, SHMPERM_TYPE * perm, int readonly)
{
int uid, gid;
mode_t mask;
Given that XShmAttach can fail (you can google the reasons), I think
maybe we need to handle that in ubiquity/cairo and fall back to an
alternative rendering method.
I'm not so sure we should be treating XShmAttach failure as a bug.
--
You received this bug notification because you are a member
** Changed in: glib2.0 (Ubuntu)
Status: Incomplete => Invalid
** Changed in: glib2.0 (Ubuntu Bionic)
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to glib2.0 in Ubuntu.
Getting closer. It's this failing in the Xorg process:
/* The attach was performed with root privs. We must
* do manual checking of access rights for the credentials
* of the client */
if (shm_access(client, &(SHM_PERM(buf)), stuff->readOnly) == -1) {
Possibly relevant to permissions: The uid of this process changed from
'root' in 17.10 (where it works), to 'ubuntu' in 18.04 (where it doesn't
work).
ubuntu4468 17.8 1.2 502716 97352 tty1 Sl+ 08:17 0:01
/usr/bin/python3 /usr/lib/ubiquity/bin/ubiquity gtk_ui
In both cases the Xorg
The BadAccess from ShmAttach is coming from the Xorg process somewhere
in here:
static int
ProcShmAttach(ClientPtr client)
{
SHMSTAT_TYPE buf;
ShmDescPtr shmdesc;
REQUEST(xShmAttachReq);
REQUEST_SIZE_MATCH(xShmAttachReq);
LEGAL_NEW_RESOURCE(stuff->shmseg, client);
if
Thanks @pjsingh5000. Your attachment shows the python stack ends at:
# There's still work to do (postinstall). Let's keep the user
# entertained.
self.start_slideshow()
Gtk.main()
Which agrees with what I see on screen when the bug occurs. It's the
slideshow that
According to this page, the problem possibly started in ubiquity version
18.04.11:
https://errors.ubuntu.com/problem/84a5563af3d2b85f098da832ece4cb8450bfd524
** Description changed:
The Ubuntu installer crashes on hiDPI machines (QHD/UHD etc). Although
it was working some weeks/months ago,
This one also started in version 18.04.11:
https://errors.ubuntu.com/problem/735a2b847e0eeab6c8a7b954de5110e43889be15
But this one started in 18.04.3:
https://errors.ubuntu.com/problem/82f7f7e7923663c7b2123c7f1f49af29f6ff4d77
--
You received this bug notification because you are a member of
** Also affects: oem-priority
Importance: Undecided
Status: New
** Changed in: oem-priority
Status: New => Triaged
** Changed in: oem-priority
Importance: Undecided => Critical
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is
Here is the backtrace (bt f) with debug symbols.
I still have gdb open, if anyone needs me to do anything else?
** Attachment added: "gdb backtrace (bt f) with debug symbols"
On an Dell XPS 9360 with a 3200x1800 display it also defaults to 200%
and I reliably reproduce this bug with the 18.04 final image.
I can confirm setting the scaling to 100% in the live session resolved
the crash.
--
You received this bug notification because you are a member of Ubuntu
Desktop
It has been brought to my attention by a community user, that the
workaround (change scale from 200% to 100%) found in comment#14 works.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to glib2.0 in Ubuntu.
Correction:
Possibly worth noting is that size==4096 at scale 200%, and size==1024 at scale
100%.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1751252
Title:
[regression]
Here's the offending source code up to the failing X call. I'm not so
sure that the math is right (or how getting it wrong might trigger this
bug)...
static cairo_xlib_shm_t *
_cairo_xlib_shm_pool_create(cairo_xlib_display_t *display,
size_t size, void **ptr)
{
27 matches
Mail list logo
