Discussion:
emacs locked when internet connection is cut...
(too old to reply)
Jean-Christophe Helary
2018-05-01 08:37:48 UTC
Permalink
I was doing things with package.el when my connection got cut. Just when emacs was trying to contact melpa.org:80...

The UI is locked, and even when I'm back online (I'm sending this mail), emacs does not seem to notice...

Shouldn't there be a timeout for any function that requires external ressources like an internet connection ? The current behavior is *extremely* inconvenient...


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune
Eli Zaretskii
2018-05-01 14:56:13 UTC
Permalink
Date: Tue, 1 May 2018 17:37:48 +0900
I was doing things with package.el when my connection got cut. Just when emacs was trying to contact melpa.org:80...
The UI is locked, and even when I'm back online (I'm sending this mail), emacs does not seem to notice...
Shouldn't there be a timeout for any function that requires external ressources like an internet connection ? The current behavior is *extremely* inconvenient...
We do have timeouts, and use async APIs where possible. Evidently, it
somehow doesn't work in your case. But you didn't give enough
information to start digging into the problem. Assuming this is
reproducible, please attach a debugger to Emacs when it hangs like
that and show the C-level backtrace. Please report the results as a
bug, using report-emacs-bug, which will also collect several important
aspects of your build and setup.

Armed with that knowledge, we might be able to investigate this
problem.

Thanks.
Jean-Christophe Helary
2018-05-02 06:56:27 UTC
Permalink
Eli,

Thank you for the instructions.

I've reconfigured emacs to make debugging easier (./configure --enable-checking='yes,glyphs' --enable-check-lisp-object-type CFLAGS='-O0 -g3') re-"make install"-ed it and launched gdb attached to its PID.

I can't seem to be able to run gdb and attach emacs without getting a lot of error messages so I'm wondering if there is a better way to get what you need to investigate into this issue.

JC
Post by Eli Zaretskii
Date: Tue, 1 May 2018 17:37:48 +0900
I was doing things with package.el when my connection got cut. Just when emacs was trying to contact melpa.org:80...
The UI is locked, and even when I'm back online (I'm sending this mail), emacs does not seem to notice...
Shouldn't there be a timeout for any function that requires external ressources like an internet connection ? The current behavior is *extremely* inconvenient...
We do have timeouts, and use async APIs where possible. Evidently, it
somehow doesn't work in your case. But you didn't give enough
information to start digging into the problem. Assuming this is
reproducible, please attach a debugger to Emacs when it hangs like
that and show the C-level backtrace. Please report the results as a
bug, using report-emacs-bug, which will also collect several important
aspects of your build and setup.
Armed with that knowledge, we might be able to investigate this
problem.
Thanks.
Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune
Eli Zaretskii
2018-05-02 14:56:08 UTC
Permalink
Date: Wed, 2 May 2018 15:56:27 +0900
I've reconfigured emacs to make debugging easier (./configure --enable-checking='yes,glyphs'
--enable-check-lisp-object-type CFLAGS='-O0 -g3') re-"make install"-ed it and launched gdb attached to its
PID.
I can't seem to be able to run gdb and attach emacs without getting a lot of error messages so I'm wondering
if there is a better way to get what you need to investigate into this issue.
Which error messages do you get? They could be just warnings that can
be disregarded, ore they could be problems that will get in the way
when you run Emacs under GDB in any other way. So please show the
messages.

Hoe to run Emacs under GDB in a way that will allow you to get control
back to GDB is described in etc/DEBUG. However, attaching GDB to a
running Emacs is much easier, so maybe it's worth your while to invest
some additional effort into trying to use that.
Jean-Christophe Helary
2018-05-02 15:06:07 UTC
Permalink
Post by Eli Zaretskii
Date: Wed, 2 May 2018 15:56:27 +0900
I've reconfigured emacs to make debugging easier (./configure --enable-checking='yes,glyphs'
--enable-check-lisp-object-type CFLAGS='-O0 -g3') re-"make install"-ed it and launched gdb attached to its
PID.
I can't seem to be able to run gdb and attach emacs without getting a lot of error messages so I'm wondering
if there is a better way to get what you need to investigate into this issue.
Which error messages do you get? They could be just warnings that can
be disregarded, ore they could be problems that will get in the way
when you run Emacs under GDB in any other way. So please show the
messages.
When I attach emacs to gdb from Emacs I get this:

Attaching to process 42692
Unable to find Mach task port for process-id 42692: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
(gdb) thread.c:1555: internal-error: scoped_restore_current_thread::scoped_restore_current_thread(): Assertion `tp != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

When I start gdb from the command line and attach emacs there I get this:
Attaching to process 42692
Unable to find Mach task port for process-id 42692: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))

After investigating a bit it looks like running gdb as sudo fixes the thing (I could not create a certificate for it) but I still get this:

Attaching to process 42692
[New Thread 0x1503 of process 42692]
[New Thread 0x1603 of process 42692]
[New Thread 0x1703 of process 42692]
[New Thread 0x1803 of process 42692]
[New Thread 0x2803 of process 42692]
[New Thread 0x2903 of process 42692]
Reading symbols from /Users/suzume/Documents/Code/emacs/nextstep/Emacs.app/Contents/MacOS/Emacs...done.
Error while mapping shared library sections:
`/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit': not a shared-library: File format not recognized
Error while mapping shared library sections:
`/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit': not a shared-library: File format not recognized
Error while mapping shared library sections:
`/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon': not a shared-library: File format not recognized
Error while mapping shared library sections:
`/usr/lib/libSystem.B.dylib': not a shared-library: File format not recognized
Error while mapping shared library sections:
`/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation': not a shared-library: File format not recognized
Error while mapping shared library sections:
`/usr/lib/libxml2.2.dylib': not a shared-library: File format not recognized

and a big bunch of other similar errors.

Jean-Christophe
Post by Eli Zaretskii
Hoe to run Emacs under GDB in a way that will allow you to get control
back to GDB is described in etc/DEBUG. However, attaching GDB to a
running Emacs is much easier, so maybe it's worth your while to invest
some additional effort into trying to use that.
Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune
Eli Zaretskii
2018-05-02 15:28:06 UTC
Permalink
Date: Thu, 3 May 2018 00:06:07 +0900
Attaching to process 42692
Unable to find Mach task port for process-id 42692: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
(gdb) thread.c:1555: internal-error: scoped_restore_current_thread::scoped_restore_current_thread(): Assertion `tp != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
I didn't realize this was an Apple system...
Attaching to process 42692
[New Thread 0x1503 of process 42692]
[New Thread 0x1603 of process 42692]
[New Thread 0x1703 of process 42692]
[New Thread 0x1803 of process 42692]
[New Thread 0x2803 of process 42692]
[New Thread 0x2903 of process 42692]
Reading symbols from /Users/suzume/Documents/Code/emacs/nextstep/Emacs.app/Contents/MacOS/Emacs...done.
`/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit': not a shared-library: File format not recognized
`/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit': not a shared-library: File format not recognized
`/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon': not a shared-library: File format not recognized
`/usr/lib/libSystem.B.dylib': not a shared-library: File format not recognized
`/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation': not a shared-library: File format not recognized
`/usr/lib/libxml2.2.dylib': not a shared-library: File format not recognized
and a big bunch of other similar errors.
Do these errors, when you run as sudo, prevent GDB from displaying a
backtrace? If so, I guess you will have to use LLDB instead.
Alan Third
2018-05-03 18:14:16 UTC
Permalink
Post by Jean-Christophe Helary
Attaching to process 42692
Unable to find Mach task port for process-id 42692: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
(gdb) thread.c:1555: internal-error: scoped_restore_current_thread::scoped_restore_current_thread(): Assertion `tp != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Attaching to process 42692
Unable to find Mach task port for process-id 42692: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
To run gdb on macOS you need to follow instructions like the following:

https://gist.github.com/gravitylow/fb595186ce6068537a6e9da6d8b5b96d

otherwise it’s simply not allowed to attach to another process. (I’ve
not tried these specific instructions.)

lldb should already be signed so will work, but you’ll miss out on
some gdb specific settings in the emacs source.
--
Alan Third
Jean-Christophe Helary
2018-05-04 07:53:24 UTC
Permalink
Post by Alan Third
Post by Jean-Christophe Helary
Attaching to process 42692
Unable to find Mach task port for process-id 42692: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
(gdb) thread.c:1555: internal-error: scoped_restore_current_thread::scoped_restore_current_thread(): Assertion `tp != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Attaching to process 42692
Unable to find Mach task port for process-id 42692: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
https://gist.github.com/gravitylow/fb595186ce6068537a6e9da6d8b5b96d
Thank you Alan,

I actually had found a similar page and followed similar instruction to get a weird error message:
Unkown error = -2,147,414,007

I'm not online at the time of this writing so I can't investigate more but I will.

Jean-Christophe
Post by Alan Third
otherwise it’s simply not allowed to attach to another process. (I’ve
not tried these specific instructions.)
lldb should already be signed so will work, but you’ll miss out on
some gdb specific settings in the emacs source.
--
Alan Third
Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune
Alexis
2018-05-05 11:03:53 UTC
Permalink
Post by Jean-Christophe Helary
Post by Alan Third
To run gdb on macOS you need to follow instructions like the
https://gist.github.com/gravitylow/fb595186ce6068537a6e9da6d8b5b96d
Thank you Alan,
I actually had found a similar page and followed similar
Unkown error = -2,147,414,007
This looks like the error addressed in the comments at the above
URL:

https://gist.github.com/gravitylow/fb595186ce6068537a6e9da6d8b5b96d#gistcomment-2246776

Does following the procedure described in that comment make any
difference?


Alexis.
Jean-Christophe Helary
2018-05-07 08:03:24 UTC
Permalink
This must be a bug...

When I reconfigured emacs with --enable-checking='yes,glyphs' --enable-check-lisp-object-type CFLAGS='-O0 -g3', to attach gdb, I ended up with a build that generated an "Invalid read syntax ")" error every time I started emacs *even though I had not modified my init file* (~/.emacs.el).

Once I reverted to a normal configuration, that same init file was evaluated without any issues.

Also, When I was running emacs -q on that modified configuration the issue seemed to center on the (require 'package) line, but when I commented it out I still had the same error...

What can I do to investigate this ?

Jean-Christophe
Post by Jean-Christophe Helary
Eli,
Thank you for the instructions.
I've reconfigured emacs to make debugging easier (./configure --enable-checking='yes,glyphs' --enable-check-lisp-object-type CFLAGS='-O0 -g3') re-"make install"-ed it and launched gdb attached to its PID.
I can't seem to be able to run gdb and attach emacs without getting a lot of error messages so I'm wondering if there is a better way to get what you need to investigate into this issue.
JC
Post by Eli Zaretskii
Date: Tue, 1 May 2018 17:37:48 +0900
I was doing things with package.el when my connection got cut. Just when emacs was trying to contact melpa.org:80 <http://melpa.org/>...
The UI is locked, and even when I'm back online (I'm sending this mail), emacs does not seem to notice...
Shouldn't there be a timeout for any function that requires external ressources like an internet connection ? The current behavior is *extremely* inconvenient...
We do have timeouts, and use async APIs where possible. Evidently, it
somehow doesn't work in your case. But you didn't give enough
information to start digging into the problem. Assuming this is
reproducible, please attach a debugger to Emacs when it hangs like
that and show the C-level backtrace. Please report the results as a
bug, using report-emacs-bug, which will also collect several important
aspects of your build and setup.
Armed with that knowledge, we might be able to investigate this
problem.
Thanks.
Jean-Christophe Helary
-----------------------------------------------
Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com <http://mac4translators.blogspot.com/> @brandelune
Eli Zaretskii
2018-05-07 18:05:39 UTC
Permalink
Date: Mon, 7 May 2018 17:03:24 +0900
[Please don't cross-post to emacs-devel and help-gnu-emacs.]
This must be a bug...
When I reconfigured emacs with --enable-checking='yes,glyphs' --enable-check-lisp-object-type
CFLAGS='-O0 -g3', to attach gdb, I ended up with a build that generated an "Invalid read syntax ")" error every
time I started emacs *even though I had not modified my init file* (~/.emacs.el).
Once I reverted to a normal configuration, that same init file was evaluated without any issues.
Also, When I was running emacs -q on that modified configuration the issue seemed to center on the (require
'package) line, but when I commented it out I still had the same error...
What can I do to investigate this ?
Put a breakpoint in Fsignal, and when it reports this error, show the
backtrace.

But first, I suggest to see if you aren't hit by the fontconfig
LC_NUMERIC issue, as I wrote in the other list.

And pease show the details of your Emacs build, those that
report-emacs-bug collects. It could be important.

Loading...