GNU bug report logs - #41184
28.0.50; Crash on NS when opening text file in a possibly invalid zip archive

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 41184 in the body.
You can then email your comments to 41184 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Filipp Gunbin <fgunbin <at> fastmail.fm>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Crash on NS when opening text file in a possibly invalid
 zip archive
Date: Mon, 11 May 2020 04:52:28 +0300

[Message part 1 (text/plain, inline)]

- emacs -Q
- C-x C-f <path to attached zip> RET
- RET on the first file in archive (the one with .txt extension)

TTY emacs doesn't crash with the same recipe.

Thanks.

In GNU Emacs 28.0.50 (build 14, x86_64-apple-darwin19.2.0, NS appkit-1894.20 Version 10.15.2 (Build 19C57))
 of 2020-05-09 built on fgunbin.local
Repository revision: ae3c510696f02f01d03052f070e5ce65b4018a45
Repository branch: master
Windowing system distributor 'Apple', version 10.3.1894
System Description:  Mac OS X 10.15.2

[Фрейд Зигмунд. Вытеснение - royallib.com.txt.zip (application/zip, attachment)]

Message #8 received at 41184 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Filipp Gunbin <fgunbin <at> fastmail.fm>
Cc: 41184 <at> debbugs.gnu.org
Subject: Re: bug#41184: 28.0.50;
 Crash on NS when opening text file in a possibly invalid zip archive
Date: Mon, 11 May 2020 17:44:10 +0300

> From: Filipp Gunbin <fgunbin <at> fastmail.fm>
> Date: Mon, 11 May 2020 04:52:28 +0300
> 
> - emacs -Q
> - C-x C-f <path to attached zip> RET
> - RET on the first file in archive (the one with .txt extension)

Can you please show the backtrace?  Without that, the bug report is
only useful if the crash can be reproduced, and you shouldn't rely on
that (e.g, I couldn't reproduce it).

Message #11 received at 41184 <at> debbugs.gnu.org (full text, mbox):

From: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Filipp Gunbin <fgunbin <at> fastmail.fm>, 41184 <at> debbugs.gnu.org
Subject: Re: bug#41184: 28.0.50; Crash on NS when opening text file in a
 possibly invalid zip archive
Date: Mon, 11 May 2020 18:57:52 +0300

Eli Zaretskii <eliz <at> gnu.org> writes:

>> - emacs -Q
>> - C-x C-f <path to attached zip> RET
>> - RET on the first file in archive (the one with .txt extension)
>
> Can you please show the backtrace?  Without that, the bug report is
> only useful if the crash can be reproduced, and you shouldn't rely on
> that (e.g, I couldn't reproduce it).

For this time not only the subject contains "NS" but also the message
body contains "Mac OS X" ;-)

Can reproduce it with those steps.  Here is backtrace:

Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not satisfying: aString != nil'
abort() called
terminating with uncaught exception of type NSException

Application Specific Backtrace 1:
0   CoreFoundation                      0x00007fff32c47d07 __exceptionPreprocess + 250
1   libobjc.A.dylib                     0x00007fff6b96b5bf objc_exception_throw + 48
2   CoreFoundation                      0x00007fff32c70ec8 +[NSException raise:format:arguments:] + 88
3   Foundation                          0x00007fff3535bf3d -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 191
4   AppKit                              0x00007fff2fe991c4 -[NSWindow setTitle:] + 185
5   Emacs-x86_64-10_14                  0x000000010b22dfb1 ns_set_name_internal + 161
6   Emacs-x86_64-10_14                  0x000000010b227e8b ns_implicitly_set_name + 475
7   Emacs-x86_64-10_14                  0x000000010b08a531 gui_consider_frame_title + 609
8   Emacs-x86_64-10_14                  0x000000010b05f9fc redisplay_internal + 1324
9   Emacs-x86_64-10_14                  0x000000010b0fdbe5 read_char + 2213
10  Emacs-x86_64-10_14                  0x000000010b0fb7aa read_key_sequence + 1722
11  Emacs-x86_64-10_14                  0x000000010b0f9fac command_loop_1 + 1340
12  Emacs-x86_64-10_14                  0x000000010b180b87 internal_condition_case + 263
13  Emacs-x86_64-10_14                  0x000000010b10a120 command_loop_2 + 48
14  Emacs-x86_64-10_14                  0x000000010b1803ab internal_catch + 267
15  Emacs-x86_64-10_14                  0x000000010b24c385 command_loop.cold.1 + 69
16  Emacs-x86_64-10_14                  0x000000010b0f9073 command_loop + 131
17  Emacs-x86_64-10_14                  0x000000010b0f8fa3 recursive_edit_1 + 115
18  Emacs-x86_64-10_14                  0x000000010b0f91fb Frecursive_edit + 347
19  Emacs-x86_64-10_14                  0x000000010b0f7dd7 main + 7431
20  libdyld.dylib                       0x00007fff6cb12cc9 start + 1


--
Andrii

Message #14 received at 41184 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Cc: fgunbin <at> fastmail.fm, 41184 <at> debbugs.gnu.org
Subject: Re: bug#41184: 28.0.50; Crash on NS when opening text file in a
 possibly invalid zip archive
Date: Mon, 11 May 2020 19:51:17 +0300

> From: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
> Cc: Filipp Gunbin <fgunbin <at> fastmail.fm>,  41184 <at> debbugs.gnu.org
> Date: Mon, 11 May 2020 18:57:52 +0300
> 
> Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not satisfying: aString != nil'
> abort() called
> terminating with uncaught exception of type NSException
> 
> Application Specific Backtrace 1:
> 0   CoreFoundation                      0x00007fff32c47d07 __exceptionPreprocess + 250
> 1   libobjc.A.dylib                     0x00007fff6b96b5bf objc_exception_throw + 48
> 2   CoreFoundation                      0x00007fff32c70ec8 +[NSException raise:format:arguments:] + 88
> 3   Foundation                          0x00007fff3535bf3d -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 191
> 4   AppKit                              0x00007fff2fe991c4 -[NSWindow setTitle:] + 185
> 5   Emacs-x86_64-10_14                  0x000000010b22dfb1 ns_set_name_internal + 161
> 6   Emacs-x86_64-10_14                  0x000000010b227e8b ns_implicitly_set_name + 475
> 7   Emacs-x86_64-10_14                  0x000000010b08a531 gui_consider_frame_title + 609

Looks like some NS-specific issue with showing a strange file name in
the frame title?

Message #17 received at 41184 <at> debbugs.gnu.org (full text, mbox):

From: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: fgunbin <at> fastmail.fm, 41184 <at> debbugs.gnu.org
Subject: Re: bug#41184: 28.0.50; Crash on NS when opening text file in a
 possibly invalid zip archive
Date: Mon, 11 May 2020 21:46:38 +0300

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Terminating app due to uncaught exception
>> 'NSInternalInconsistencyException', reason: 'Invalid parameter not
>> satisfying: aString != nil'
>> abort() called
>> terminating with uncaught exception of type NSException
>>
>> Application Specific Backtrace 1:
>> 0   CoreFoundation                      0x00007fff32c47d07 __exceptionPreprocess + 250
>> 1   libobjc.A.dylib                     0x00007fff6b96b5bf objc_exception_throw + 48
>> 2   CoreFoundation                      0x00007fff32c70ec8 +[NSException raise:format:arguments:] + 88
>> 3 Foundation 0x00007fff3535bf3d -[NSAssertionHandler
>> handleFailureInMethod:object:file:lineNumber:description:] + 191
>> 4   AppKit                              0x00007fff2fe991c4 -[NSWindow setTitle:] + 185
>> 5   Emacs-x86_64-10_14                  0x000000010b22dfb1 ns_set_name_internal + 161
>> 6   Emacs-x86_64-10_14                  0x000000010b227e8b ns_implicitly_set_name + 475
>> 7   Emacs-x86_64-10_14                  0x000000010b08a531 gui_consider_frame_title + 609
>
> Looks like some NS-specific issue with showing a strange file name in
> the frame title?

You are absolutely right.

Actually crash can be reproduced with single step:

  (set-frame-name "\200")

Message #20 received at 41184 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Cc: fgunbin <at> fastmail.fm, 41184 <at> debbugs.gnu.org
Subject: Re: bug#41184: 28.0.50; Crash on NS when opening text file in a
 possibly invalid zip archive
Date: Mon, 11 May 2020 21:53:49 +0300

> From: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
> Cc: fgunbin <at> fastmail.fm,  41184 <at> debbugs.gnu.org
> Date: Mon, 11 May 2020 21:46:38 +0300
> 
> >> 4   AppKit                              0x00007fff2fe991c4 -[NSWindow setTitle:] + 185
> >> 5   Emacs-x86_64-10_14                  0x000000010b22dfb1 ns_set_name_internal + 161
> >> 6   Emacs-x86_64-10_14                  0x000000010b227e8b ns_implicitly_set_name + 475
> >> 7   Emacs-x86_64-10_14                  0x000000010b08a531 gui_consider_frame_title + 609
> >
> > Looks like some NS-specific issue with showing a strange file name in
> > the frame title?
> 
> You are absolutely right.
> 
> Actually crash can be reproduced with single step:
> 
>   (set-frame-name "\200")

It probably means the APIs used by ns_set_name_internal cannot handle
invalid UTF-8 sequences.  The code there seems to naïvely encode in
UTF-8, but doesn't have any error handling for when that fails.
Someone who knows about NS programming should add some simple
workaround, like showing a string "\200" instead of a byte \200.
Or something.

Message #23 received at 41184 <at> debbugs.gnu.org (full text, mbox):

From: Filipp Gunbin <fgunbin <at> fastmail.fm>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 41184 <at> debbugs.gnu.org
Subject: Re: bug#41184: 28.0.50; Crash on NS when opening text file in a
 possibly invalid zip archive
Date: Tue, 12 May 2020 13:44:38 +0300

On 11/05/2020 17:44 +0300, Eli Zaretskii wrote:

>> From: Filipp Gunbin <fgunbin <at> fastmail.fm>
>> Date: Mon, 11 May 2020 04:52:28 +0300
>>
>> - emacs -Q
>> - C-x C-f <path to attached zip> RET
>> - RET on the first file in archive (the one with .txt extension)
>
> Can you please show the backtrace?  Without that, the bug report is
> only useful if the crash can be reproduced, and you shouldn't rely on
> that (e.g, I couldn't reproduce it).

Sorry, my fault, I had it but forgot to insert.  I see Andrii posted a
similar one.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.