From: Liam Quinlan <liamkquinlan@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: --with-cairo Emacs server crash and fix
Date: Mon, 12 Aug 2019 06:48:25 -0400 [thread overview]
Message-ID: <CAAQqQ-1_H2Co3YqLdQABygOwOsXWaSLFfZv8-zCjwDNNjOpvQA@mail.gmail.com> (raw)
In-Reply-To: <83pnld8imb.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 6415 bytes --]
... Whoops, I guess gdb doesn't log !cmd output. Here's what should be in
that awkward empty spot.
set print pretty on
set print array on
set print array-indexes on
set style enabled off
set style sources off
set pagination off
set logging on
tbreak _start
commands
set variable $bitmap_counter = 0
continue
end
break fringe.c:1475 if once_p
commands
set variable $bitmap_counter = (which > $bitmap_counter ? which :
$bitmap_counter)
printf ">>>> init_fringe_bitmap(): end of function, once_p <<<<"
if fringe_bitmaps
set variable $loop = 0
while $loop <=q $bitmap_counter
printf "fringe_bitmaps[%d]: %p\n",$loop,fringe_bitmaps[$loop]
set variable $loop = $loop + 1
end
else
print "fringe_bitmaps == NULL"
end
printf "\n which: %d\n\n",which
continue
end
break fringe.c:1487
commands
set variable $bitmap_counter = (which > $bitmap_counter ? which :
$bitmap_counter)
printf "\n\n>>>> init_fringe_bitmap(): end of function, !once_p <<<<\n\n"
if rif
print "rif: exists"
printf "define_fringe_bitmap: %s\n",rif->define_fringe_bitmap ?
"available" : "null"
else
print "rif: unavailable"
end
set variable $loop = 0
while $loop <= $bitmap_counter
printf "fringe_bitmaps[%d]: %p\n",$loop,fringe_bitmaps[$loop]
set variable $loop = $loop + 1
end
if fringe_bmp
print ""
set variable $loop = 0
while $loop <= $bitmap_counter
printf "fringe_bmp[%d]: %p\n",$loop,fringe_bmp[$loop]
set variable $loop = $loop + 1
end
else
print "fringe_bmp == NULL"
end
printf "\n which: %d\n\n",which
continue
end
tbreak emacs.c:2086
commands
printf "\n\n>>>> main(): emacs.c <<<<\n\n"
printf "$bitmap_counter: %d\n",$bitmap_counter
set variable $loop = 0
while $loop <= $bitmap_counter
printf "fringe_bitmaps[%d]: %p\n",$loop,fringe_bitmaps[$loop]
set variable $loop = $loop + 1
end
if fringe_bmp
print ""
set variable $loop = 0
while $loop <= $bitmap_counter
printf "fringe_bmp[%d]: %p\n",$loop,fringe_bmp[$loop]
set variable $loop = $loop + 1
end
else
printf "fringe_bmp == NULL\n\n"
end
printf "\n\n\n\
>>>>>>>>>>>>>====================================<<<<<<<<<<<<< \n\
This is the end of the pre-local-load phase of startup. \n\
So far nothing has gone wrong. Next, that changes. \n\
>>>>>>>>>>>>>====================================<<<<<<<<<<<<< \n\n\n"
tbreak pselect
commands
printf "\n\n\n\
>>>>>>>>>>>>>====================================<<<<<<<<<<<<< \n\
Here's the *actual* end of what happens before connecting \n\
a client session. \n\
We've loaded three dynamic bitmaps from package files. \n\
They've been initialized into fringe_bitmaps, and so far as\n\
emacs is concerned, are ready to use should GUI client \n\
connect later. But our test for whether initializing those\n\
bitmaps required calling rif->define_fringe_bitmap(), ie, \n\
'rif && rif->define_fringe_bitmap', came up false. \n\
Obviously that's not true; when we start a GUI frame we \n\
will need the cairo structures it creates. The way things \n\
stand, they won't be, but emacs will assume they are and \n\
try to use them. \n\n\
Connecting a client frame and opening a file that will \n\
cause us to try to draw the bitmaps... \n\
>>>>>>>>>>>>>====================================<<<<<<<<<<<<< \n\n\n"
continue
end
continue
end
printf "\n\n ================================= \n\n\
CWD: ~/self/workbench/emacs/master/src\n\
CMDLINE: gdb -x ../../cairo_bug/gdb_script \\\n\
--args ./emacs --fg-daemon=cairo \n\n\
gdb_script contents: \n\n"
!cat ../../cairo_bug/gdb_script
printf "\n\nhere goes nothing...\n\n"
On Sat, Aug 10, 2019, 05:39 Eli Zaretskii, <eliz@gnu.org> wrote:
> > From: Liam Quinlan <liamkquinlan@gmail.com>
> > Date: Fri, 9 Aug 2019 11:40:21 -0400
> >
> > It is definitely specific to cairo builds. The 'fringe_bmp' array (not
> to be confused with the 'fringe_bitmaps'
> > array) has a cairo api type and is declared behind #ifdef USE_CAIRO.
>
> I see a similar (w32-specific) variable in the MS-Windows build, so
> this is at least relevant to MS-Windows as well.
>
> > I *think* the minimal init file to reproduce is actually '-Q'...
> provided you can get flymake to display its error
> > fringe indicator, which embarrassingly I cannot (no backends will run...
> definitely unrelated, probably self
> > inflicted). Assuming you can accomplish this (flymake-error-bitmap
> uses flymake-double-exclaimation-mark,
> > flymake-fringe-indicator-position isn't nil, fringe-mode is on, etc),
> the steps to reproduce are very simple:
> >
> > 1. build --with-cairo, using any x toolkit
> > 2. start an emacs server with --daemon option (ie don't 'M-x
> server-mode')
> > 3: connect normally with emacsclient
> > 4: open a file with syntax errors and more than one screen of text
> > 5: get flymake to display its error indicators
> > 6: scroll up and down. It won't take very long.
>
> Can you please show a C-level backtrace from the crash, and also the
> result of xbacktrace (this will be automatic if you start GDB in the
> Emacs src/ directory)? Without that, I'm not sure I understand the
> scenario, since after the emacsclient connection Emacs already has a
> fringe-capable frame, so fringe related code should work. I'm
> probably missing something.
>
> Also, I'd like to be able to reproduce without flymake. There are
> built-in features that define bitmaps, like indicate-buffer-boundaries
> and indicate-empty-lines; can they be used to reproduce the problem
> instead of flymake?
>
> > Should it prove easier somehow flycheck and sesman also define custom
> bitmaps, either of which will do. It
> > can be any fringe-bitmap defined in package that gets loaded during the
> daemon process's own startup.
> > Packages that don't load until emacsclient connects are fine, as by that
> point an x frame exists and
> > SELECTED_FRAME will work.
>
> See, you are talking about "packages loaded during startup", but
> didn't show any init files to that effect. This makes it hard to
> reproduce the problem and debug it independently.
>
> Thanks.
>
[-- Attachment #2: Type: text/html, Size: 10615 bytes --]
next prev parent reply other threads:[~2019-08-12 10:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-09 15:40 --with-cairo Emacs server crash and fix Liam Quinlan
2019-08-10 9:39 ` Eli Zaretskii
2019-08-12 10:42 ` Liam Quinlan
2019-08-12 10:48 ` Liam Quinlan [this message]
2019-08-12 16:59 ` Eli Zaretskii
2019-08-12 20:00 ` Liam Quinlan
2019-08-13 2:52 ` Liam Quinlan
2019-08-13 15:00 ` Eli Zaretskii
2019-08-13 17:36 ` Liam Quinlan
-- strict thread matches above, loose matches on Subject: below --
2019-08-08 7:01 Liam Quinlan
2019-08-09 7:11 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAQqQ-1_H2Co3YqLdQABygOwOsXWaSLFfZv8-zCjwDNNjOpvQA@mail.gmail.com \
--to=liamkquinlan@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.