* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written @ 2012-11-16 20:48 Drew Adams 2012-11-16 21:05 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files " Drew Adams 2012-11-16 21:19 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files " Stefan Monnier 0 siblings, 2 replies; 59+ messages in thread From: Drew Adams @ 2012-11-16 20:48 UTC (permalink / raw) To: 12911 Please do not write such files willy nilly to the directory where the Emacs process was opened (or whatever). That is not user-friendly. Please let users decide where to write such files. Consider even giving them the option to prevent Emacs from writing such files altogether (short of giving up using Emacs completely). If such user control is not possible, then please confine such files to somewhere under .emacs.d or some other "hidden" directory that is typically far from the files that a user accesses using Emacs or other applications. Users do not want program-debugging information written to their folder of family vacation photos or their favorite lasagna recipes. Think _user_. Emacs is about users. In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600) of 2012-11-05 on MS-W7-DANI Bzr revision: 110809 lekktu@gmail.com-20121105172930-a5gn0bwi4lndchhw Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.7) --no-opt --enable-checking --cflags -I../../libs/libXpm-3.5.10/include -I../../libs/libXpm-3.5.10/src -I../../libs/libpng-1.2.37-lib/include -I../../libs/zlib-1.2.5 -I../../libs/giflib-4.1.4-1-lib/include -I../../libs/jpeg-6b-4-lib/include -I../../libs/tiff-3.8.2-1-lib/include -I../../libs/libxml2-2.7.8-w32-bin/include/libxml2 -I../../libs/gnutls-3.0.9-w32-bin/include -I../../libs/libiconv-1.9.2-1-lib/include' ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written 2012-11-16 20:48 bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Drew Adams @ 2012-11-16 21:05 ` Drew Adams 2012-11-16 21:19 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files " Stefan Monnier 1 sibling, 0 replies; 59+ messages in thread From: Drew Adams @ 2012-11-16 21:05 UTC (permalink / raw) To: 12911 Please see bug #12908 for the start of the discussion (some arguments pro/con etc.). That might obviate some repetition here. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-16 20:48 bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Drew Adams 2012-11-16 21:05 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files " Drew Adams @ 2012-11-16 21:19 ` Stefan Monnier 2012-11-17 7:26 ` Eli Zaretskii 1 sibling, 1 reply; 59+ messages in thread From: Stefan Monnier @ 2012-11-16 21:19 UTC (permalink / raw) To: Drew Adams; +Cc: 12911 > If such user control is not possible, then please confine such files to > somewhere under .emacs.d or some other "hidden" directory that is Agreed: writing the file into ~/.emacs.d makes a lot more sense. Stefan ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-16 21:19 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files " Stefan Monnier @ 2012-11-17 7:26 ` Eli Zaretskii 2012-11-17 17:38 ` Drew Adams 2012-11-19 1:52 ` Stefan Monnier 0 siblings, 2 replies; 59+ messages in thread From: Eli Zaretskii @ 2012-11-17 7:26 UTC (permalink / raw) To: Stefan Monnier; +Cc: 12911 > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Fri, 16 Nov 2012 16:19:33 -0500 > Cc: 12911@debbugs.gnu.org > > > If such user control is not possible, then please confine such files to > > somewhere under .emacs.d or some other "hidden" directory that is > > Agreed: writing the file into ~/.emacs.d makes a lot more sense. I agree, but we need to decide what to do if this directory is remote, because invoking file handlers in this situation is not possible. Also, on Unix, the information is under the home directory, and the Unix builds don't themselves create any files, but rather reuse system-wide settings (which AFAIU aren't settable by users). So I'm unsure what this means for platforms other than Windows. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-17 7:26 ` Eli Zaretskii @ 2012-11-17 17:38 ` Drew Adams 2012-11-17 17:55 ` Eli Zaretskii 2012-11-19 1:52 ` Stefan Monnier 1 sibling, 1 reply; 59+ messages in thread From: Drew Adams @ 2012-11-17 17:38 UTC (permalink / raw) To: 'Eli Zaretskii', 'Stefan Monnier'; +Cc: 12911 BTW, just a thought, in ignorance - ignore if not helpful. The backtrace file, wherever it might be saved: does it get overwritten when there is a new crash, or is a new version of it created (e.g. emacs_backtrace.txt~259~)? In either case, I assume that it would be good for a user to send a bug report with (at least) the latest such file. Would it be possible/useful for a new Emacs session to (a) look for such a file, (b) if found then automatically compose a bug-report message, and (c) ask the user whether to send it? And then (d) perhaps optionally delete the file? IOW, isn't there some easy way for Emacs Dev to get such info semi-automatically - upon user agreement/confirmation? Emacs should know where to look for the file, or at least be able to recognize it if seen by accident. And Emacs should be able to pick up the latest such file if there are multiple versions. Or perhaps it could combine all such files in a given directory into a single bug report, separating the backtraces and timestamping them with the file dates. Just a thought. Seems like we are expecting users to do things that they might not know, care, or bother about doing, when some of the more bothersome lifting for that could perhaps be done automatically by a subsequent Emacs session. Any such automatic activity must of course be able to be turned off/on by users, i.e., an option (opt-in or opt-out). I imagine that you guys have already thought about such things, and perhaps dismissed the idea, but I thought I'd mention it anyway, just in case. Again, ignore if not helpful. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-17 17:38 ` Drew Adams @ 2012-11-17 17:55 ` Eli Zaretskii 2012-11-17 18:24 ` Drew Adams 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-11-17 17:55 UTC (permalink / raw) To: Drew Adams; +Cc: 12911 > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <12911@debbugs.gnu.org> > Date: Sat, 17 Nov 2012 09:38:10 -0800 > > The backtrace file, wherever it might be saved: does it get overwritten when > there is a new crash, or is a new version of it created (e.g. > emacs_backtrace.txt~259~)? On MS-Windows, neither: the new backtrace gets appended to the file. I don't know what happens on Unix. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-17 17:55 ` Eli Zaretskii @ 2012-11-17 18:24 ` Drew Adams 0 siblings, 0 replies; 59+ messages in thread From: Drew Adams @ 2012-11-17 18:24 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: 12911 > > The backtrace file, wherever it might be saved: does it get > > overwritten when there is a new crash, or is a new version > > of it created (e.g. emacs_backtrace.txt~259~)? > > On MS-Windows, neither: the new backtrace gets appended to the file. > I don't know what happens on Unix. OK. Same question though - would it make sense for a subsequent Emacs session, if it finds the file, to prepare a bug-report message that includes the info in the file and propose that the user send it? And perhaps then delete the file? (All with user approval, of course.) ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-17 7:26 ` Eli Zaretskii 2012-11-17 17:38 ` Drew Adams @ 2012-11-19 1:52 ` Stefan Monnier 2012-11-19 3:51 ` Eli Zaretskii 1 sibling, 1 reply; 59+ messages in thread From: Stefan Monnier @ 2012-11-19 1:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12911 >> > If such user control is not possible, then please confine such files to >> > somewhere under .emacs.d or some other "hidden" directory that is >> Agreed: writing the file into ~/.emacs.d makes a lot more sense. > I agree, but we need to decide what to do if this directory is remote, > because invoking file handlers in this situation is not possible. The file name should be passed straight to the OS without going through file-name-handlers. If the OS thinks the directory doesn't exit: no big deal! > Also, on Unix, the information is under the home directory, and the > Unix builds don't themselves create any files, but rather reuse > system-wide settings (which AFAIU aren't settable by users). So I'm > unsure what this means for platforms other than Windows. No need to change anything on platforms where stderr works. Stefan ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-19 1:52 ` Stefan Monnier @ 2012-11-19 3:51 ` Eli Zaretskii 2012-11-19 4:07 ` Stefan Monnier 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-11-19 3:51 UTC (permalink / raw) To: Stefan Monnier; +Cc: 12911 > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Sun, 18 Nov 2012 20:52:43 -0500 > > No need to change anything on platforms where stderr works. stderr works on Windows as well. See the code I wrote. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-19 3:51 ` Eli Zaretskii @ 2012-11-19 4:07 ` Stefan Monnier 2012-11-19 15:52 ` Eli Zaretskii 0 siblings, 1 reply; 59+ messages in thread From: Stefan Monnier @ 2012-11-19 4:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12911 >> No need to change anything on platforms where stderr works. > stderr works on Windows as well. See the code I wrote. If stderr works, then why do we need emacs_backtrace.txt? Stefan ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-19 4:07 ` Stefan Monnier @ 2012-11-19 15:52 ` Eli Zaretskii 2012-11-19 18:04 ` Stefan Monnier 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-11-19 15:52 UTC (permalink / raw) To: Stefan Monnier; +Cc: 12911 > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Sun, 18 Nov 2012 23:07:25 -0500 > > >> No need to change anything on platforms where stderr works. > > stderr works on Windows as well. See the code I wrote. > > If stderr works, then why do we need emacs_backtrace.txt? For when the stuff written to stderr ends up in the Great Void, or scrolls off the screen, or whatever. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-19 15:52 ` Eli Zaretskii @ 2012-11-19 18:04 ` Stefan Monnier 2012-11-19 18:13 ` Eli Zaretskii 0 siblings, 1 reply; 59+ messages in thread From: Stefan Monnier @ 2012-11-19 18:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12911 >> >> No need to change anything on platforms where stderr works. >> > stderr works on Windows as well. See the code I wrote. >> If stderr works, then why do we need emacs_backtrace.txt? > For when the stuff written to stderr ends up in the Great Void, or > scrolls off the screen, or whatever. Right. That's what I meant by "stderr doesn't work" (IOW while it does work in some cases, it can't be relied upon). So let me reword my suggestion: I suggested to change the code such that, in those cases where we need to use emacs_backtrace.txt, we use ~/.emacs.d/backtrace.txt instead. Stefan ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-19 18:04 ` Stefan Monnier @ 2012-11-19 18:13 ` Eli Zaretskii 2012-11-19 18:35 ` Stefan Monnier 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-11-19 18:13 UTC (permalink / raw) To: Stefan Monnier; +Cc: 12911 > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Mon, 19 Nov 2012 13:04:20 -0500 > > >> >> No need to change anything on platforms where stderr works. > >> > stderr works on Windows as well. See the code I wrote. > >> If stderr works, then why do we need emacs_backtrace.txt? > > For when the stuff written to stderr ends up in the Great Void, or > > scrolls off the screen, or whatever. > > Right. That's what I meant by "stderr doesn't work" (IOW while it does > work in some cases, it can't be relied upon). But then your first sentence above applies not only to Windows, because stderr "doesn't work" in this sense on Unix as well. > So let me reword my suggestion: > > I suggested to change the code such that, in those cases where we need > to use emacs_backtrace.txt, we use ~/.emacs.d/backtrace.txt instead. I already agreed to this, provided that Emacs puts stderr output there on all platforms. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-19 18:13 ` Eli Zaretskii @ 2012-11-19 18:35 ` Stefan Monnier 2012-11-19 18:40 ` Eli Zaretskii 0 siblings, 1 reply; 59+ messages in thread From: Stefan Monnier @ 2012-11-19 18:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12911 >> >> >> No need to change anything on platforms where stderr works. >> >> > stderr works on Windows as well. See the code I wrote. >> >> If stderr works, then why do we need emacs_backtrace.txt? >> > For when the stuff written to stderr ends up in the Great Void, or >> > scrolls off the screen, or whatever. >> Right. That's what I meant by "stderr doesn't work" (IOW while it does >> work in some cases, it can't be relied upon). > But then your first sentence above applies not only to Windows, > because stderr "doesn't work" in this sense on Unix as well. I don't know of any case under Unix where stderr is dumped into the great void (except for cases where the user would then also want the backtrace to be dumped in that great void). >> So let me reword my suggestion: >> I suggested to change the code such that, in those cases where we need >> to use emacs_backtrace.txt, we use ~/.emacs.d/backtrace.txt instead. > I already agreed to this, provided that Emacs puts stderr output there > on all platforms. Yes, on all platforms where emacs_backtrace.txt is needed (in practice, this does reduce to w32, AFAIK). Stefan ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-19 18:35 ` Stefan Monnier @ 2012-11-19 18:40 ` Eli Zaretskii 2012-11-19 19:47 ` Stefan Monnier 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-11-19 18:40 UTC (permalink / raw) To: Stefan Monnier; +Cc: 12911 > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Mon, 19 Nov 2012 13:35:15 -0500 > > >> >> >> No need to change anything on platforms where stderr works. > >> >> > stderr works on Windows as well. See the code I wrote. > >> >> If stderr works, then why do we need emacs_backtrace.txt? > >> > For when the stuff written to stderr ends up in the Great Void, or > >> > scrolls off the screen, or whatever. > >> Right. That's what I meant by "stderr doesn't work" (IOW while it does > >> work in some cases, it can't be relied upon). > > But then your first sentence above applies not only to Windows, > > because stderr "doesn't work" in this sense on Unix as well. > > I don't know of any case under Unix where stderr is dumped into the > great void It can still scroll off the screen. Or end up in some file that the window-system developers or admins set up, and that is some random or unknown place, as far as Emacs users and maintainers are concerned. I see no significant difference. > >> So let me reword my suggestion: > >> I suggested to change the code such that, in those cases where we need > >> to use emacs_backtrace.txt, we use ~/.emacs.d/backtrace.txt instead. > > I already agreed to this, provided that Emacs puts stderr output there > > on all platforms. > > Yes, on all platforms where emacs_backtrace.txt is needed (in practice, > this does reduce to w32, AFAIK). No, on _all_ platforms. But I'm repeating myself. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-19 18:40 ` Eli Zaretskii @ 2012-11-19 19:47 ` Stefan Monnier 2012-11-19 20:05 ` Eli Zaretskii 0 siblings, 1 reply; 59+ messages in thread From: Stefan Monnier @ 2012-11-19 19:47 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12911 >> I don't know of any case under Unix where stderr is dumped into the >> great void > It can still scroll off the screen. Or end up in some file that the > window-system developers or admins set up, and that is some random or > unknown place, as far as Emacs users and maintainers are concerned. > I see no significant difference. The difference is that the above cases are hypothetical, whereas the w32 case is the norm. >> >> So let me reword my suggestion: >> >> I suggested to change the code such that, in those cases where we need >> >> to use emacs_backtrace.txt, we use ~/.emacs.d/backtrace.txt instead. >> > I already agreed to this, provided that Emacs puts stderr output there >> > on all platforms. >> Yes, on all platforms where emacs_backtrace.txt is needed (in practice, >> this does reduce to w32, AFAIK). > No, on _all_ platforms. We disagree on the "is needed" part. I'm not sure that w32 is the only one where it's needed, but so far the need hasn't cropped up elsewhere. Maybe macsox needs it as well? Stefan ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-19 19:47 ` Stefan Monnier @ 2012-11-19 20:05 ` Eli Zaretskii 2012-11-19 21:15 ` Stefan Monnier 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-11-19 20:05 UTC (permalink / raw) To: Stefan Monnier; +Cc: 12911 > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Mon, 19 Nov 2012 14:47:26 -0500 > > >> I don't know of any case under Unix where stderr is dumped into the > >> great void > > It can still scroll off the screen. Or end up in some file that the > > window-system developers or admins set up, and that is some random or > > unknown place, as far as Emacs users and maintainers are concerned. > > I see no significant difference. > > The difference is that the above cases are hypothetical, whereas the w32 > case is the norm. Neither is correct. I just had the backtrace on GNU/Linux scroll off on me (a TTY session crashed). And I almost always invoke Emacs on Windows in a way that leaves stderr output around. But that is besides the point. For J.R. Hacker who reads the manual, what matters is what happens on her machine, not the statistical average. And what happens on her machine could well be that stderr ends up in some random place on her disk. As long as that is a real possibility, writing emacs_backtrace.txt in the directory it is written now on Windows is equivalent to what happens on Unix. Making it in ~/.emacs.d on w32 alone doesn't change the basic fact that most of the users we care about will still have their backtraces in random places. Why not change that on all platforms? Why demand that only of w32? For that matter, why do you care so much about w32 users? > >> >> So let me reword my suggestion: > >> >> I suggested to change the code such that, in those cases where we need > >> >> to use emacs_backtrace.txt, we use ~/.emacs.d/backtrace.txt instead. > >> > I already agreed to this, provided that Emacs puts stderr output there > >> > on all platforms. > >> Yes, on all platforms where emacs_backtrace.txt is needed (in practice, > >> this does reduce to w32, AFAIK). > > No, on _all_ platforms. > > We disagree on the "is needed" part. No, we disagree about the importance of uniformity in operation across platforms. Either the data is in a platform-specific place, in which case the current arrangement is as good as any, or it is in the same Emacs-specific place on all platforms. The latter is the arrangement I'd support and it will give me enough motivation to spend more effort on this (although I'm not sure I have any energy left after this longish discussion). ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-19 20:05 ` Eli Zaretskii @ 2012-11-19 21:15 ` Stefan Monnier 2012-11-20 3:58 ` Eli Zaretskii 0 siblings, 1 reply; 59+ messages in thread From: Stefan Monnier @ 2012-11-19 21:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12911 > Making it in ~/.emacs.d on w32 alone doesn't change the basic fact > that most of the users we care about will still have their backtraces > in random places. No, ~/.xsesson-errors is not a random place. Even if the user doesn't know it, we do. > Why not change that on all platforms? Because stderr is good enough under GNU/Linux (and it's easy to redirect when it matters). > Why demand that only of w32? Because currently w32 users get annoyed with new files appearing where they don't want any. If you prefer to always send it to stderr under Windows, please do so, I really couldn't care less if that means it's usually sent to /dev/null. > No, we disagree about the importance of uniformity in operation across > platforms. I suggested above another way to be uniform across platforms. > Either the data is in a platform-specific place, in which > case the current arrangement is as good as any, No, writing to an arbitrary file in the current directory is not a good arrangement. I personally don't care whether it's uniform across platforms or not. I didn't like the backtrace business to start with and am finding it worse by the day. And it doesn't even give me the info that the old "assert in a macro" gave me. Stefan ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-19 21:15 ` Stefan Monnier @ 2012-11-20 3:58 ` Eli Zaretskii 2012-11-20 4:59 ` Stefan Monnier 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-11-20 3:58 UTC (permalink / raw) To: Stefan Monnier; +Cc: 12911 > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org > Date: Mon, 19 Nov 2012 16:15:17 -0500 > > > Making it in ~/.emacs.d on w32 alone doesn't change the basic fact > > that most of the users we care about will still have their backtraces > > in random places. > > No, ~/.xsesson-errors is not a random place. Even if the user doesn't > know it, we do. This place is also platform-specific. Not on every Posix platform stderr is put there. > > Why not change that on all platforms? > > Because stderr is good enough under GNU/Linux (and it's easy to > redirect when it matters). And the current arrangement on Windows is good enough for that system. > > Why demand that only of w32? > > Because currently w32 users get annoyed with new files appearing where > they don't want any. Only one user complained so far. > If you prefer to always send it to stderr under Windows, please do > so, I really couldn't care less if that means it's usually sent to > /dev/null. Well, I do care, so I wrote the code to be better than that. > No, writing to an arbitrary file in the current directory is not > a good arrangement. I disagree, obviously. > I didn't like the backtrace business to start with and am finding it > worse by the day. Should I say "told you so"? ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-20 3:58 ` Eli Zaretskii @ 2012-11-20 4:59 ` Stefan Monnier 2012-11-20 5:02 ` Daniel Colascione 2012-11-20 16:36 ` Juanma Barranquero 0 siblings, 2 replies; 59+ messages in thread From: Stefan Monnier @ 2012-11-20 4:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12911 >> Because currently w32 users get annoyed with new files appearing where >> they don't want any. > Only one user complained so far. FWIW, I'd be annoyed if I were a w32 user and had to deal with emacs_backtrace.txt files appearing in directories without my saying so explicitly. Stefan ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-20 4:59 ` Stefan Monnier @ 2012-11-20 5:02 ` Daniel Colascione 2012-11-20 13:16 ` Andy Moreton 2012-11-20 17:03 ` Eli Zaretskii 2012-11-20 16:36 ` Juanma Barranquero 1 sibling, 2 replies; 59+ messages in thread From: Daniel Colascione @ 2012-11-20 5:02 UTC (permalink / raw) To: Stefan Monnier; +Cc: 12911 [-- Attachment #1: Type: text/plain, Size: 467 bytes --] On 11/19/2012 8:59 PM, Stefan Monnier wrote: >>> Because currently w32 users get annoyed with new files appearing where >>> they don't want any. >> Only one user complained so far. > > FWIW, I'd be annoyed if I were a w32 user and had to deal with > emacs_backtrace.txt files appearing in directories without my saying > so explicitly. I agree that the behavior is bad. If we really need these emacs_backtrace.txt, they should go under %LOCALAPPDATA%. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 258 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-20 5:02 ` Daniel Colascione @ 2012-11-20 13:16 ` Andy Moreton 2012-11-20 16:27 ` Eli Zaretskii 2012-11-20 17:03 ` Eli Zaretskii 1 sibling, 1 reply; 59+ messages in thread From: Andy Moreton @ 2012-11-20 13:16 UTC (permalink / raw) To: 12911 On Tue 20 Nov 2012, Daniel Colascione wrote: > On 11/19/2012 8:59 PM, Stefan Monnier wrote: >>>> Because currently w32 users get annoyed with new files appearing where >>>> they don't want any. >>> Only one user complained so far. >> >> FWIW, I'd be annoyed if I were a w32 user and had to deal with >> emacs_backtrace.txt files appearing in directories without my saying >> so explicitly. > > I agree that the behavior is bad. If we really need these emacs_backtrace.txt, > they should go under %LOCALAPPDATA%. Given that the backtrace does not include symbols, it seems fairly useless to me. I'd vote for getting rid of it on all platforms. AndyM ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-20 13:16 ` Andy Moreton @ 2012-11-20 16:27 ` Eli Zaretskii 0 siblings, 0 replies; 59+ messages in thread From: Eli Zaretskii @ 2012-11-20 16:27 UTC (permalink / raw) To: Andy Moreton; +Cc: 12911 > From: Andy Moreton <andrewjmoreton@gmail.com> > Date: Tue, 20 Nov 2012 13:16:18 +0000 > > Given that the backtrace does not include symbols, it seems fairly > useless to me. I'd vote for getting rid of it on all platforms. I'd be the last to defend the feature, but out of fairness: symbolic information (i.e. file names and source line numbers) are one command away. See the manual for details. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-20 5:02 ` Daniel Colascione 2012-11-20 13:16 ` Andy Moreton @ 2012-11-20 17:03 ` Eli Zaretskii 2012-11-20 17:36 ` Daniel Colascione 2012-11-20 18:30 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Stefan Monnier 1 sibling, 2 replies; 59+ messages in thread From: Eli Zaretskii @ 2012-11-20 17:03 UTC (permalink / raw) To: Daniel Colascione; +Cc: 12911 > Date: Mon, 19 Nov 2012 21:02:22 -0800 > From: Daniel Colascione <dancol@dancol.org> > CC: Eli Zaretskii <eliz@gnu.org>, 12911@debbugs.gnu.org > > On 11/19/2012 8:59 PM, Stefan Monnier wrote: > >>> Because currently w32 users get annoyed with new files appearing where > >>> they don't want any. > >> Only one user complained so far. > > > > FWIW, I'd be annoyed if I were a w32 user and had to deal with > > emacs_backtrace.txt files appearing in directories without my saying > > so explicitly. > > I agree that the behavior is bad. If we really need these emacs_backtrace.txt, > they should go under %LOCALAPPDATA%. Maybe you guys think I've decided to put the file in the current directory without any thought, just because I find it easier not to futz with leading directories. That's far from being true. I did invest some thought and a bit of research before making a decision. Look, we are talking about emergency measures. Not some normal feature that writes files as a matter of habit. Emacs is going down in flames, and we want at the last moment to get some information from it. Code that does that must be as simple and as reliable as possible, or it will not work, or, worse, cause nested exceptions that will completely obscure the original cause. %LOCALAPPDATA%? It doesn't exist on XP and earlier systems. There's only %APPDATA% there. To distinguish, we'd need to probe the OS version, or try both places. That means more system API calls. Not rocket science, but still: complications, at the time that every tweak counts. (Incidentally, %APPDATA% is what we by default treat as HOME, a directory that I'm told is full of lasagna recipes we are not allowed to contaminate.) Accessing environment variables is another problematic place. We are crashing, so the heap or the whole arena can be trashed. Who can be sure the environment variables will not point to garbled places? And what if the %LOCALAPPDATA% doesn't exist as an environment variable? We'd need to access the Registry. More complications and API calls. Someone else suggested to write into the directory where the Emacs binary is installed. But latest Windows versions make the directory where programs are installed write-protected, especially if the user has Administrator privileges. Worse, there's this thing called "filesystem virtualization", whereby the program is allowed to write to those directories, but the data is actually redirected into some hidden directory no one can find, even if they know about this. Etc., etc. Yes, the current directory is far from ideal. But on balance, I find it the lesser evil, and my long experience on MS-Windows tells me that it is still the best choice for data you must reliably write somewhere. (Of course, Stefan says that he doesn't care if the data is lost, so all of the above doesn't matter to him. But, as long as we have this feature, I _do_ care, otherwise I wouldn't have sit down and written it. Arguments whose authors don't care cannot possibly convince me. If we _really_ don't care, let's go ahead and rip out the whole feature. That'd be at least honest.) ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-20 17:03 ` Eli Zaretskii @ 2012-11-20 17:36 ` Daniel Colascione 2012-11-20 18:02 ` Eli Zaretskii 2012-11-20 18:30 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Stefan Monnier 1 sibling, 1 reply; 59+ messages in thread From: Daniel Colascione @ 2012-11-20 17:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12911 [-- Attachment #1: Type: text/plain, Size: 2054 bytes --] On 11/20/12 9:03 AM, Eli Zaretskii wrote: >> Date: Mon, 19 Nov 2012 21:02:22 -0800 >> From: Daniel Colascione <dancol@dancol.org> >> CC: Eli Zaretskii <eliz@gnu.org>, 12911@debbugs.gnu.org >> >> On 11/19/2012 8:59 PM, Stefan Monnier wrote: >>>>> Because currently w32 users get annoyed with new files appearing where >>>>> they don't want any. >>>> Only one user complained so far. >>> >>> FWIW, I'd be annoyed if I were a w32 user and had to deal with >>> emacs_backtrace.txt files appearing in directories without my saying >>> so explicitly. >> >> I agree that the behavior is bad. If we really need these emacs_backtrace.txt, >> they should go under %LOCALAPPDATA%. > > %LOCALAPPDATA%? It doesn't exist on XP and earlier systems. There's > only %APPDATA% there. To distinguish, we'd need to probe the OS > version, or try both places. That means more system API calls. Not > rocket science, but still: complications, at the time that every tweak > counts. > Accessing environment variables is another problematic place. > And what if the %LOCALAPPDATA% doesn't exist as an environment > variable? We'd need to access the Registry. Compute the name of the backtrace file when Emacs starts. A crash is unlikely to corrupt a single allocation. > (Incidentally, %APPDATA% is what we by default treat as HOME, a > directory that I'm told is full of lasagna recipes we are not allowed > to contaminate.) %USERPROFILE% is where I put my lasagna recipes. %APPDATA% is full of non-user-visible application data on my system. Is %APPDATA% actually a user-visible directory of some sort on XP? > We are > crashing, so the heap or the whole arena can be trashed. Who can be > sure the environment variables will not point to garbled places? A process cannot reliably report all of its own crashes. That's why Windows Error Reporting monitors processes with a service and collects dumps of crashing processes from outside, in a separate process. Collecting information about most crashes is adequate. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 235 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-20 17:36 ` Daniel Colascione @ 2012-11-20 18:02 ` Eli Zaretskii 2012-11-20 18:57 ` bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' " Drew Adams 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-11-20 18:02 UTC (permalink / raw) To: Daniel Colascione; +Cc: 12911 > Date: Tue, 20 Nov 2012 09:36:36 -0800 > From: Daniel Colascione <dancol@dancol.org> > CC: monnier@iro.umontreal.ca, 12911@debbugs.gnu.org > > Compute the name of the backtrace file when Emacs starts. Sorry, as long as this is a Windows-specific issue, I don't have any motivation to go to that length. > > (Incidentally, %APPDATA% is what we by default treat as HOME, a > > directory that I'm told is full of lasagna recipes we are not allowed > > to contaminate.) > > %USERPROFILE% is where I put my lasagna recipes. %APPDATA% is full of > non-user-visible application data on my system. That's another sign of what I said earlier: there's no home directory on Windows. Yet another candidate is "My Documents" (e.g., bzr uses it). But none of them is really for the user, according to Windows guidelines. > Is %APPDATA% actually a user-visible directory of some sort on XP? Yes. Each user is the owner of her %APPDATA%, and has full access rights. That directory is for applications to put their per-user data. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' files are written 2012-11-20 18:02 ` Eli Zaretskii @ 2012-11-20 18:57 ` Drew Adams 2012-11-20 19:58 ` Eli Zaretskii 0 siblings, 1 reply; 59+ messages in thread From: Drew Adams @ 2012-11-20 18:57 UTC (permalink / raw) To: 'Eli Zaretskii', 'Daniel Colascione'; +Cc: 12911 > Yet another candidate is "My Documents" (e.g., bzr uses > it). But none of them is really for the user, according to Windows > guidelines. Really? I don't know (or care too much) what Windows guidelines might say about this. But I would be mildly curious about that, if you happen to have a URL. Everyone I know considers `My Documents' and its subfolders to be a user folder - maybe even *THE* user folder par excellence. There is even a `My Documents' folder for each user defined for the machine. (Another name for it can be Administrator's Documents, Drew's Documents, Eli's Documents. etc.) Pretty clear to me that this intended to separate one users documents from those of another user, as well as from non-user documents. Why any program (e.g. bzr, apparently) would want to consider that folder as fair game for stuffing its internal stuff is beyond me. How impolite. Anyway, let's see what good ol' Wikipedia has to say... http://en.wikipedia.org/wiki/My_Documents My Documents is the name of a special folder on the computer's hard drive that the system commonly uses to store a user's documents, music, pictures, downloads, and other files. Whaddya know? And it says `My Documents' was introduced, "as a standard location for storing user-created files." Hm. That all sounds just like what I think about it. And about its subfolders, including `My Music',... That "My" should tell us something, I would think. `My Documents' is not the kind of place a civilized program would want to pollute with its own crap. Now of course, installing a program might well create a subfolder under `My Documents' that is intended for user-created data that is specific to that program - e.g. music files you save. Nothing wrong with that. That is not the same as a place to stuff program-internal data. We have `Program Files' and user-specific `Local Settings\Application Data' for that kind of thing. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' files are written 2012-11-20 18:57 ` bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' " Drew Adams @ 2012-11-20 19:58 ` Eli Zaretskii 2012-11-20 21:47 ` Drew Adams 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-11-20 19:58 UTC (permalink / raw) To: Drew Adams; +Cc: 12911 > X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, > RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <12911@debbugs.gnu.org> > Date: Tue, 20 Nov 2012 10:57:00 -0800 > > > Yet another candidate is "My Documents" (e.g., bzr uses > > it). But none of them is really for the user, according to Windows > > guidelines. > > Really? I don't know (or care too much) what Windows guidelines might say about > this. But I would be mildly curious about that, if you happen to have a URL. http://msdn.microsoft.com/en-us/library/windows/desktop/bb762494%28v=vs.85%29.aspx > Everyone I know considers `My Documents' and its subfolders to be a user folder > - maybe even *THE* user folder par excellence. "The file system directory used to physically store a user's common repository of documents." What do you make of that? "User's documents", not "user's files". > There is even a `My Documents' folder for each user defined for the machine. > (Another name for it can be Administrator's Documents, Drew's Documents, Eli's > Documents. etc.) Yes, that's the "virtual folder" part in the description on the above URL. But then you also have per-user "Application Data", "Temporary Internet Files", "Favorites", and many more. Being per user does not mean it's up for grabs for any particular purpose. > Why any program (e.g. bzr, apparently) would want to consider that folder as > fair game for stuffing its internal stuff is beyond me. How impolite. Not at all. It is customary, at least on Unix, to put logs, command history, and other similar files in the user's home directory. > Anyway, let's see what good ol' Wikipedia has to say... > http://en.wikipedia.org/wiki/My_Documents > > My Documents is the name of a special folder on the computer's > hard drive that the system commonly uses to store a user's > documents, music, pictures, downloads, and other files. > > Whaddya know? And it says `My Documents' was introduced, "as a standard > location for storing user-created files." Don't believe everything Wikipedia says. > Hm. That all sounds just like what I think about it. And about its subfolders, > including `My Music',... That "My" should tell us something, I would think. Then why did that "My" part disappear in latest Windows versions? There's no C:\Users\<username>\Documents etc., with "My Documents" just a symlink. See http://windows.microsoft.com/is-IS/windows-vista/What-happened-to-My-Documents > `My Documents' is not the kind of place a civilized program would want to > pollute with its own crap. It's _your_ crap, because it's _you_ who runs that program. > That is not the same as a place to stuff program-internal data. We have > `Program Files' and user-specific `Local Settings\Application Data' for that > kind of thing. As I wrote earlier, writing to "Program Files" is a bad idea, as it is not writable in Vista and later. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' files are written 2012-11-20 19:58 ` Eli Zaretskii @ 2012-11-20 21:47 ` Drew Adams 2012-11-21 3:47 ` Eli Zaretskii 0 siblings, 1 reply; 59+ messages in thread From: Drew Adams @ 2012-11-20 21:47 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: 12911 > "The file system directory used to physically store a user's common > repository of documents." What do you make of that? "User's > documents", not "user's files". A distinction without a meaning, in the present context. Trouncing user stuff is a no-no, whether that stuff is "documents" or files. The distinction that matters here is user vs application. The distinction between documents and files is a red herring, unless I'm missing something. > Yes, that's the "virtual folder" part in the description on the above > URL. But then you also have per-user "Application Data", "Temporary > Internet Files", "Favorites", and many more. Being per user does not > mean it's up for grabs for any particular purpose. I'm certainly not arguing that `My Documents' should be up for grabs by a program for any particular purpose. Far from it. Well behaved programs store user-specific internal data in places like `Application Data', NOT in `My Documents'. User-specific program data is not the same thing as user data. You do not seem to want to recognize any difference between a user's photo of his grandmother and a cache file used by a program to optimize access to that photo. (Hint: the user cares about Grandma; s?he does not care about the cache.) Why such a refusal to admit the obvious? Is this about arguing and winning an argument, or is it about progressing toward a solution? You seem to want to emphasize the continuum and shades of gray, whose existence no one would dispute, as an excuse not to recognize any distinction at all between the ends of the spectrum. (It's all connected; each electron is spread out and penetrates the entire universe. All is o n e.) It is not all the same. Red is not blue, even if there is a continuum of wavelengths. A program keeping to itself and its internal program thingies is more likely to be well behaved than one that refuses to recognize any difference between itself and the user. > Not at all. It is customary, at least on Unix, to put logs, > command history, and other similar files in the user's home > directory. Yes, and it is just as customary, or at least likely, that Unix user Eunice will put her documents/files in specific subdirectories under $HOME, and not just sprinkle them at the top level of $HOME. (Not to mention the custom/handling (e.g. by listing programs, shell, and various commands) of "hidden" dot files. All is not equal, even on Unix.) Argue this as you might for Unix, it is certainly the case on MS Windows, at least, that it is customary for users NOT to mix their own documents/files in with system data or application data. And it is just as customary for applications not to mix their data with user documents/files. It's hard for me to believe this is even a point open to debate. > Don't believe everything Wikipedia says. You don't seem to want to believe your own eyes. The existence of green does not prove that red is blue. > Then why did that "My" part disappear in latest Windows versions? > There's no C:\Users\<username>\Documents etc., with "My Documents" > just a symlink. > http://windows.microsoft.com/is-IS/windows-vista/What-happened-to-My-Documents Irrelevant. (And you could have learned the same thing if you had read the Wikipedia entry I cited, BTW.) > > `My Documents' is not the kind of place a civilized program > > would want to pollute with its own crap. > > It's _your_ crap, because it's _you_ who runs that program. There you go again. That, I guess, is your core argument: it's all o n e. Sorry, I reject that argument entirely. I won't repeat the reasons, unless you really want me to. Red is not blue. User-specific app data is not the same thing as user data. Your program is not Eunice User, even if Eunice chooses to use your program. Sure, if you ask her whether you can put your stuff in her folder, and she says yes, then things are a bit different. Then we're talking mutual consent, not violation. ;-) The question is what Emacs can do to minimize intrusion/annoyance. Perhaps you'd prefer an opt-in EUA that Eunice must acknowledge in order to use Emacs, and containing a provision that Emacs reserves the right to stick its stuff anywhere at all? Yes, in that case, by agreeing, Emacs's crap becomes Eunice's crap. I hope we can avoid that. > > That is not the same as a place to stuff program-internal > > data. We have `Program Files' and user-specific `Local > > Settings\Application Data' for that kind of thing. > > As I wrote earlier, writing to "Program Files" is a bad idea, > as it is not writable in Vista and later. I said that programs store internal data in such places, and they do. Whether they also use `Program Files' to write new files to, once installed, is another matter. (And I don't hear you making the same claim wrt `Application Data', BTW.) Eli, please stop arguing peripheral minutiae. Store program-internal data where other programs do (on Windows). That's all. 'Nuff said. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' files are written 2012-11-20 21:47 ` Drew Adams @ 2012-11-21 3:47 ` Eli Zaretskii 2012-11-21 4:03 ` Daniel Colascione 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-11-21 3:47 UTC (permalink / raw) To: Drew Adams; +Cc: 12911 > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <dancol@dancol.org>, <12911@debbugs.gnu.org> > Date: Tue, 20 Nov 2012 13:47:38 -0800 > > > "The file system directory used to physically store a user's common > > repository of documents." What do you make of that? "User's > > documents", not "user's files". > > A distinction without a meaning, in the present context. Trouncing user stuff > is a no-no, whether that stuff is "documents" or files. That's your interpretation. It isn't written anywhere. > The distinction that matters here is user vs application. There's no distinction. > You do not seem to want to recognize any difference between a user's photo of > his grandmother and a cache file used by a program to optimize access to that > photo. (Hint: the user cares about Grandma; s?he does not care about the > cache.) Your hint is wrong. I care about my caches dearly. > It's hard for me to believe this is even a point open to debate. Well, it evidently is, and you fail to convince. You are just repeating yourself. > > Don't believe everything Wikipedia says. > > You don't seem to want to believe your own eyes. I believe my experience. > Store program-internal data where other programs do (on Windows). Which is everywhere and nowhere. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' files are written 2012-11-21 3:47 ` Eli Zaretskii @ 2012-11-21 4:03 ` Daniel Colascione 2012-11-21 15:43 ` Juanma Barranquero 0 siblings, 1 reply; 59+ messages in thread From: Daniel Colascione @ 2012-11-21 4:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12911 [-- Attachment #1: Type: text/plain, Size: 307 bytes --] On 11/20/2012 7:47 PM, Eli Zaretskii wrote: >> Store program-internal data where other programs do (on Windows). > > Which is everywhere and nowhere. All my other programs store program-generated files under AppData. None writes indiscriminately to the current directory in the event of a crash. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 258 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' files are written 2012-11-21 4:03 ` Daniel Colascione @ 2012-11-21 15:43 ` Juanma Barranquero 2012-11-21 16:24 ` bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' filesare written Drew Adams 0 siblings, 1 reply; 59+ messages in thread From: Juanma Barranquero @ 2012-11-21 15:43 UTC (permalink / raw) To: Daniel Colascione; +Cc: 12911 On Wed, Nov 21, 2012 at 5:03 AM, Daniel Colascione <dancol@dancol.org> wrote: > All my other programs store program-generated files under AppData. None writes > indiscriminately to the current directory in the event of a crash. Do you have many Windows programs that do generate a backtrace file in the event of failure? And do they all write to %APPDATA%? If the answer to both questions is "yes", are these Cygwin programs? Juanma ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' filesare written 2012-11-21 15:43 ` Juanma Barranquero @ 2012-11-21 16:24 ` Drew Adams [not found] ` <E86D7DFBD2BD4C3394E5316EF0321A! 95@us.oracle.com> 2012-11-21 16:45 ` Juanma Barranquero 0 siblings, 2 replies; 59+ messages in thread From: Drew Adams @ 2012-11-21 16:24 UTC (permalink / raw) To: 'Juanma Barranquero', 'Daniel Colascione'; +Cc: 12911 > > All my other programs store program-generated files under > > AppData. None writes indiscriminately to the current directory > > in the event of a crash. > > Do you have many Windows programs that do generate a backtrace file in > the event of failure? And do they all write to %APPDATA%? > > If the answer to both questions is "yes", are these Cygwin programs? Why not add "and whose name is `Emacs'" while you're at it? Seriously, this is not only about applications that generate a backtrace file. It's about the etiquette that applications generally respect on Windows, in order to respect the user and user data. Why narrow it to applications that write backtrace files? Is there something particular about that case which should exclude it from respecting of the normal etiquette? Sure, if a program absolutely CANNOT respect the expected behavior because of some hard constraint, then maybe that's a reason to make it an exception. So far, we haven't seen such a reason, AFAICT. It might not be super simple for Emacs to DTRT here, but that's not the same thing as saying that it CANNOT do so. And of course we have several decades of Emacs use without this new feature, in which Emacs has not found it necessary to go beyond the pale. ^ permalink raw reply [flat|nested] 59+ messages in thread
[parent not found: <E86D7DFBD2BD4C3394E5316EF0321A! 95@us.oracle.com>]
* bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' filesare written 2012-11-21 16:24 ` bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' filesare written Drew Adams [not found] ` <E86D7DFBD2BD4C3394E5316EF0321A! 95@us.oracle.com> @ 2012-11-21 16:45 ` Juanma Barranquero 2012-11-21 17:40 ` Drew Adams 1 sibling, 1 reply; 59+ messages in thread From: Juanma Barranquero @ 2012-11-21 16:45 UTC (permalink / raw) To: Drew Adams; +Cc: 12911 On Wed, Nov 21, 2012 at 5:24 PM, Drew Adams <drew.adams@oracle.com> wrote: > Why not add "and whose name is `Emacs'" while you're at it? Because that would not make sense. > Seriously, this is not only about applications that generate a backtrace file. Yes, it is, because David said "[n]one writes indiscriminately to the current directory in the event of a crash", and... > It's about the etiquette that applications generally respect on Windows, in > order to respect the user and user data. ...Emacs does NOT write files at random here and there. We're specifically talking about a situation where Emacs is going down in flames, and Eli choose a simple answer that does not require checking remote accesses or environment variables. I would agree with you if Emacs were prone to writing files in unexpected places, but a crash backtrace is an exceptional circumstance. Again: I understand that you're worried because you've said that crashes are almost a daily occurrence for you. But I use the trunk [Stefan: not really, I'm using emacs-24, I swear] and I cannot remember the last time I had a crash other than assertion failures after some sweeping "cleanup". Juanma ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' filesare written 2012-11-21 16:45 ` Juanma Barranquero @ 2012-11-21 17:40 ` Drew Adams 2012-11-21 17:43 ` Juanma Barranquero 0 siblings, 1 reply; 59+ messages in thread From: Drew Adams @ 2012-11-21 17:40 UTC (permalink / raw) To: 'Juanma Barranquero'; +Cc: 12911 > Again: I understand that you're worried because you've said that > crashes are almost a daily occurrence for you. But I use the trunk > [Stefan: not really, I'm using emacs-24, I swear] and I cannot > remember the last time I had a crash other than assertion failures > after some sweeping "cleanup". NOT AT ALL. Totally irrelevant. This has nothing to do with me or my setup or the frequency with which I experience crashes with Emacs 24. I think you will find no mention by me in the bug report I filed for this, or in any of my correspondence in the bug thread, of my daily crashes with Emacs 24 or my concern for my own sake. Red herring - you are apparently grasping at straws. My concern is that Emacs be respectful of users (not particularly me). For my personal use I could not care less where Emacs sticks backtrace files. As to your argument that this is exceptional because Emacs is going down in flames: I think Stefan has already spoken to that. We have a choice in that context regarding how polite Emacs should try to be. I would say very polite - as polite as Emacs has always been. You seem to be saying that we cannot afford to be so polite when Rome is burning. And I'm guessing you might also say that we cannot even give users the choice as to how polite Emacs needs to be here, because when you're going down in flames you cannot be checking user options (we've heard that wrt env vars). We can agree to disagree about this. To me, it is more important that Emacs respect users than it is that Emacs save (and hopefully later send to Emacs Dev) each and every backtrace. We've gotten by OK for decades now without such an annoyance. And we can apparently (IIUC) find ways to get at least some such backtrace feedback (i.e, sometimes) without the annoyance. IIUC, Stefan and Eli have both said that it is only in some cases that Emacs would not be able to save the backtrace data, if we required Emacs to respect users and stay out of their folders. (However, I'm no expert on the implementation question, and it's quite possible I have misunderstood.) I say that if that is the case then Emacs Dev should pay the (small) price and forego those particular backtraces. Not a big deal, IMHO. Not as big a deal as, in effect, telling users that Emacs does not care about their data. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' filesare written 2012-11-21 17:40 ` Drew Adams @ 2012-11-21 17:43 ` Juanma Barranquero 2012-11-21 18:01 ` Drew Adams 0 siblings, 1 reply; 59+ messages in thread From: Juanma Barranquero @ 2012-11-21 17:43 UTC (permalink / raw) To: Drew Adams; +Cc: 12911 On Wed, Nov 21, 2012 at 6:40 PM, Drew Adams <drew.adams@oracle.com> wrote: > Red herring - you are apparently grasping at straws. Thanks, it is always great to be read in such a favorable light. > You seem to be > saying that we cannot afford to be so polite when Rome is burning. No, I'm saying that this is much ado about almost nothing. Juanma ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' filesare written 2012-11-21 17:43 ` Juanma Barranquero @ 2012-11-21 18:01 ` Drew Adams 2012-11-21 18:13 ` Juanma Barranquero 0 siblings, 1 reply; 59+ messages in thread From: Drew Adams @ 2012-11-21 18:01 UTC (permalink / raw) To: 'Juanma Barranquero'; +Cc: 12911 > > Red herring - you are apparently grasping at straws. > > Thanks, it is always great to be read in such a favorable light. Sorry if I hurt your feelings somehow. But what would you call it, bringing my personal use of Emacs into the discussion as if it were the motivation behind my filing the bug report and arguing for a fix? It is not, at all. To me, that red herring (which it is) was an ad hominem turn in the road - let's look at Drew, not Drew's message. Irrelevant to the discussion. And far removed from any argument I have made here. Don't get me wrong. I do not say that it was an ad hominem attack in any way; it was not an attack. It was just an irrelevant distraction. But let me know if I'm missing something in your argument. And again, sorry if something I said caused hard feelings - none were intended. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' filesare written 2012-11-21 18:01 ` Drew Adams @ 2012-11-21 18:13 ` Juanma Barranquero 2012-11-21 18:42 ` Drew Adams 0 siblings, 1 reply; 59+ messages in thread From: Juanma Barranquero @ 2012-11-21 18:13 UTC (permalink / raw) To: Drew Adams; +Cc: 12911 On Wed, Nov 21, 2012 at 7:01 PM, Drew Adams <drew.adams@oracle.com> wrote: > To me, that red herring (which it is) was an ad hominem turn in the road - let's > look at Drew, not Drew's message. Mine wasn't an ad hominem, because I haven't said that your arguments are wrong because they are yours. I think they are wrong because they put emphasis in something that happens very rarely, and suggest adding complexity to something that is very simple. AND I've *pointed out* that the relative importance of that problem is greater for you than for me, because you are more likely to get affected by it. That could affect your judgment (it would likely affect mine; I get angry when people who doesn't ever use line-by-line scrolling start suggesting changes to scroll-conservatively and Emacs recentering, or when non-Windows users suggest that some changes won't affect the Windows port, or that if they do affect it, is all Microsoft's fault). > Don't get me wrong. I do not say that it was an ad hominem attack in any way; > it was not an attack. It was just an irrelevant distraction. I find an irrelevant distraction that you're discussing "[...] the etiquette that applications generally respect on Windows, in order to respect the user and user data" when the thread is specifically about *one* file, in *one* specific situation, which is a crash backtrace. Juanma ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' filesare written 2012-11-21 18:13 ` Juanma Barranquero @ 2012-11-21 18:42 ` Drew Adams 0 siblings, 0 replies; 59+ messages in thread From: Drew Adams @ 2012-11-21 18:42 UTC (permalink / raw) To: 'Juanma Barranquero'; +Cc: 12911 > I find an irrelevant distraction that you're discussing "[...] the > etiquette that applications generally respect on Windows, in order to > respect the user and user data" when the thread is specifically about > *one* file, in *one* specific situation, which is a crash backtrace. It's in fact as far as you can get from irrelevant. That's precisely what this bug report is about: the placement by Emacs of that "*one* file, in *one* specific situation, which is a crash backtrace", into a user folder. So perhaps this bug report is altogether irrelevant and a distraction to you. Fair enough. What can I say, in that case? We're back to agreeing to disagree. I think that that *one* case of disrespecting users should be removed; you think that that regression should stay, because it is an improvement. We apparently do not disagree about the other cases for this new feature: the cases where user folders are not written into. We both are in favor of the new feature in those cases. We apparently disagree only about that *one* corner case, where Emacs apparently cannot do otherwise than to write its backtrace into a user folder. That's the case this bug report is about. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-20 17:03 ` Eli Zaretskii 2012-11-20 17:36 ` Daniel Colascione @ 2012-11-20 18:30 ` Stefan Monnier 2012-11-20 18:37 ` Eli Zaretskii 1 sibling, 1 reply; 59+ messages in thread From: Stefan Monnier @ 2012-11-20 18:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12911 > Accessing environment variables is another problematic place. We are > crashing, so the heap or the whole arena can be trashed. Who can be > sure the environment variables will not point to garbled places? Just to put things in perspective: this backtrace "feature" was put in to replace/supplement the previous assertion failure output (because with asserts now being inside inlinable functions, the line&file info we get is not the one we want any more). So the environment is usually still pretty sane, because assertions are usually caught fairly early. Of course, there will be cases where the process is sufficiently botched up that we can't build the file name ~/.emacs.d/backtrace.txt, while we might still be able to just use "backtrace.txt" successfully, but I don't think those borderline cases are sufficiently common to be worry about them. Stefan ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-20 18:30 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Stefan Monnier @ 2012-11-20 18:37 ` Eli Zaretskii 2012-11-20 20:15 ` Stefan Monnier 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-11-20 18:37 UTC (permalink / raw) To: Stefan Monnier; +Cc: 12911 > From: Stefan Monnier <monnier@IRO.UMontreal.CA> > Cc: Daniel Colascione <dancol@dancol.org>, 12911@debbugs.gnu.org > Date: Tue, 20 Nov 2012 13:30:52 -0500 > > > Accessing environment variables is another problematic place. We are > > crashing, so the heap or the whole arena can be trashed. Who can be > > sure the environment variables will not point to garbled places? > > Just to put things in perspective: this backtrace "feature" was put in > to replace/supplement the previous assertion failure output (because > with asserts now being inside inlinable functions, the line&file info > we get is not the one we want any more). So the environment is usually > still pretty sane, because assertions are usually caught fairly early. If the backtrace is created due to assertion violation, yes. But it is also invoked for all the other fatal signals. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-20 18:37 ` Eli Zaretskii @ 2012-11-20 20:15 ` Stefan Monnier 0 siblings, 0 replies; 59+ messages in thread From: Stefan Monnier @ 2012-11-20 20:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12911 >> > Accessing environment variables is another problematic place. We are >> > crashing, so the heap or the whole arena can be trashed. Who can be >> > sure the environment variables will not point to garbled places? >> Just to put things in perspective: this backtrace "feature" was put in >> to replace/supplement the previous assertion failure output (because >> with asserts now being inside inlinable functions, the line&file info >> we get is not the one we want any more). So the environment is usually >> still pretty sane, because assertions are usually caught fairly early. > If the backtrace is created due to assertion violation, yes. But it > is also invoked for all the other fatal signals. Yes, but the only case I care about is the assertion violation. The other cases have never generated any useful output in the past anyway and nobody complained abut that. Stefan ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-20 4:59 ` Stefan Monnier 2012-11-20 5:02 ` Daniel Colascione @ 2012-11-20 16:36 ` Juanma Barranquero 2012-11-20 17:11 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files " Drew Adams 2012-11-20 17:49 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files " Eli Zaretskii 1 sibling, 2 replies; 59+ messages in thread From: Juanma Barranquero @ 2012-11-20 16:36 UTC (permalink / raw) To: Stefan Monnier; +Cc: 12911 On Tue, Nov 20, 2012 at 5:59 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > FWIW, I'd be annoyed if I were a w32 user and had to deal with > emacs_backtrace.txt files appearing in directories without my saying > so explicitly. Windows binaries for official releases (as opposed to trunk snapshots) rarely crash. It's not as if the user is going to get backtraces all over his hard disk on every single run. Juanma ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written 2012-11-20 16:36 ` Juanma Barranquero @ 2012-11-20 17:11 ` Drew Adams 2012-11-20 17:53 ` Eli Zaretskii 2012-11-20 17:49 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files " Eli Zaretskii 1 sibling, 1 reply; 59+ messages in thread From: Drew Adams @ 2012-11-20 17:11 UTC (permalink / raw) To: 'Juanma Barranquero', 'Stefan Monnier'; +Cc: 12911 > > FWIW, I'd be annoyed if I were a w32 user and had to deal with > > emacs_backtrace.txt files appearing in directories without my saying > > so explicitly. > > Windows binaries for official releases (as opposed to trunk snapshots) > rarely crash. It's not as if the user is going to get backtraces all > over his hard disk on every single run. FWIW, that is not my experience, not with Emacs 24. Official Emacs binaries 24.1 and 24.2 crash for me, seemingly randomly, sooner or later, pretty much each time I use them - and I don't get to use them for long. If I had a recipe I would send it along. I sent an emacs-backtrace.txt file recently, which Eli said should be useful, but no news yet on whether it helped fix some bug. ;-) I agree, however, that a user is not going to be getting backtraces all over the place. That's some consolation, but not reason enough by itself to introduce this regression, IMHO (just one opinion). As Eli himself said - and was the first to point out AFAIK (http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00501.html): EZ> Based on my experience, I expect this "feature" to be hated, EZ> by users and Emacs maintainers alike. I think he's likely to be right in that guess. And he points out several reasons against introducing this feature (reasons I'm not qualified to judge). Eli also said, there: EZ> using the limited information it provides can be quite difficult Whether the feature is worth the various drawbacks mentioned, I, for one, cannot say. But it sure would be good to find a way to put these backtrace files somewhere other than a user folder. That I will say. FWIW, both Emacs maintainers have seemed to agree. Yidong said this (http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00870.html): CY> Littering the filesystem with these backtrace files is CY> kind of obnoxious. Certainly, plopping them into user folders is. User data is not for Emacs to fiddle with uninvited, and that includes folders. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written 2012-11-20 17:11 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files " Drew Adams @ 2012-11-20 17:53 ` Eli Zaretskii 2012-11-20 18:10 ` Drew Adams 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-11-20 17:53 UTC (permalink / raw) To: Drew Adams; +Cc: lekktu, 12911 > From: "Drew Adams" <drew.adams@oracle.com> > Date: Tue, 20 Nov 2012 09:11:46 -0800 > Cc: 12911@debbugs.gnu.org > > I sent an emacs-backtrace.txt file recently Where? I must have missed that, or maybe forgot. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written 2012-11-20 17:53 ` Eli Zaretskii @ 2012-11-20 18:10 ` Drew Adams 2012-11-20 18:27 ` Eli Zaretskii 0 siblings, 1 reply; 59+ messages in thread From: Drew Adams @ 2012-11-20 18:10 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: lekktu, 12911 > > I sent an emacs-backtrace.txt file recently > > Where? I must have missed that, or maybe forgot. The first mail that started this discussion: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12908 This is the exchange we had about it: EZ>>>> Users should include it with their bug reports. DA>>> DA>>> Does my having included it in this bug report help in some DA>>> way? I'm guessing no, but would love to be shown wrong. EZ>> EZ>> Your guess is wrong, that file includes enough information EZ>> to understand where the crash happened, and in some cases EZ>> also why. DA> DA> That's good news. Let's hope it helps fix some of the DA> crashing problems. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written 2012-11-20 18:10 ` Drew Adams @ 2012-11-20 18:27 ` Eli Zaretskii 2012-11-20 19:15 ` Dani Moncayo 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-11-20 18:27 UTC (permalink / raw) To: Drew Adams, Dani Moncayo; +Cc: lekktu, 12911 > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <lekktu@gmail.com>, <monnier@iro.umontreal.ca>, <12911@debbugs.gnu.org> > Date: Tue, 20 Nov 2012 10:10:30 -0800 > > > > I sent an emacs-backtrace.txt file recently > > > > Where? I must have missed that, or maybe forgot. > > The first mail that started this discussion: > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12908 Thanks. Dani, where can I find the binary which fits this: In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600) of 2012-11-05 on MS-W7-DANI Bzr revision: 110809 lekktu <at> gmail.com-20121105172930-a5gn0bwi4lndchhw Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.7) --no-opt --enable-checking --cflags -I../../libs/libXpm-3.5.10/include -I../../libs/libXpm-3.5.10/src -I../../libs/libpng-1.2.37-lib/include -I../../libs/zlib-1.2.5 -I../../libs/giflib-4.1.4-1-lib/include -I../../libs/jpeg-6b-4-lib/include -I../../libs/tiff-3.8.2-1-lib/include -I../../libs/libxml2-2.7.8-w32-bin/include/libxml2 -I../../libs/gnutls-3.0.9-w32-bin/include -I../../libs/libiconv-1.9.2-1-lib/include' Or maybe you (Dani) can run addr2line on that binary and tell what you get from Drew's backtraces. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written 2012-11-20 18:27 ` Eli Zaretskii @ 2012-11-20 19:15 ` Dani Moncayo 2012-11-20 19:41 ` Eli Zaretskii 0 siblings, 1 reply; 59+ messages in thread From: Dani Moncayo @ 2012-11-20 19:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, 12911 [-- Attachment #1: Type: text/plain, Size: 1547 bytes --] >> > > I sent an emacs-backtrace.txt file recently >> > >> > Where? I must have missed that, or maybe forgot. >> >> The first mail that started this discussion: >> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12908 > > Thanks. > > Dani, where can I find the binary which fits this: (I've caught this by chance - I was not in the "to" or the "cc") You can get the binary from https://www.dropbox.com/sh/7jr3vbv9tm1zod0/jPuvfrJAe8 The file to pick up is obvious looking at the revno (110809). > In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600) > of 2012-11-05 on MS-W7-DANI > Bzr revision: 110809 lekktu <at> gmail.com-20121105172930-a5gn0bwi4lndchhw > Windowing system distributor `Microsoft Corp.', version 5.1.2600 > Configured using: > `configure --with-gcc (4.7) --no-opt --enable-checking --cflags > -I../../libs/libXpm-3.5.10/include -I../../libs/libXpm-3.5.10/src > -I../../libs/libpng-1.2.37-lib/include -I../../libs/zlib-1.2.5 > -I../../libs/giflib-4.1.4-1-lib/include > -I../../libs/jpeg-6b-4-lib/include > -I../../libs/tiff-3.8.2-1-lib/include > -I../../libs/libxml2-2.7.8-w32-bin/include/libxml2 > -I../../libs/gnutls-3.0.9-w32-bin/include > -I../../libs/libiconv-1.9.2-1-lib/include' > > Or maybe you (Dani) can run addr2line on that binary and tell what you > get from Drew's backtraces. I'm never done that, but I've tried it: addr2line -e emacs.exe < bt-in.txt > bt-out.txt where the "emacs.exe" is the one from the build used by Drew. I'm attaching both files. HTH. -- Dani Moncayo [-- Attachment #2: bt-in.txt --] [-- Type: text/plain, Size: 1752 bytes --] Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x012072B8 0x012080B9 0x0103B54F 0x0104F14B 0x01038878 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x01063E40 0x010030FF 0x01001411 0x01021A07 0x01208B6F 0x01206FA0 0x01203D74 0x0103B556 0x0104F14B 0x01038878 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01144D4F 0x01144D2A 0x01144D83 0x010011E6 0x7C8438F6 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01144D4F 0x01144D2A 0x01144D83 0x010011E6 0x7C8438F6 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x01063E40 0x010030FF 0x01001411 0x01021A07 0x01271987 0x012753CF 0x01201334 0x01202410 0x0121160D 0x01208C14 0x01010FC6 0x01208BA1 0x01206FA0 0x01203D74 0x0103B556 0x0104F14B 0x01038878 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x010EFEEA 0x010F6A68 0x010F5208 0x010F48F4 0x010F4616 0x0120710E 0x01203D74 0x0103B556 0x0104F14B 0x01038878 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01144D4F 0x01144D2A 0x01144D83 0x010011E6 0x7C8438F6 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x012D32D3 0x01014F64 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E6C1C 0x01014FD5 0x01014733 0x01052C55 0x010390C7 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 [-- Attachment #3: bt-out.txt --] [-- Type: text/plain, Size: 4768 bytes --] ??:0 c:\emacs\trunk\src/w32fns.c:7717 c:\emacs\trunk\src/w32fns.c:7749 c:\emacs\trunk\src/emacs.c:345 c:\emacs\trunk\src/alloc.c:6440 c:\emacs\trunk\src/xdisp.c:13540 c:\emacs\trunk\src/xdisp.c:13748 c:\emacs\trunk\src/keyboard.c:2426 c:\emacs\trunk\src/keyboard.c:9223 c:\emacs\trunk\src/keyboard.c:1458 c:\emacs\trunk\src/eval.c:1288 c:\emacs\trunk\src/keyboard.c:1167 c:\emacs\trunk\src/eval.c:1059 c:\emacs\trunk\src/keyboard.c:1146 c:\emacs\trunk\src/keyboard.c:778 c:\emacs\trunk\src/keyboard.c:842 c:\emacs\trunk\src/emacs.c:1564 crt1.c:0 ??:0 ??:0 ??:0 c:\emacs\trunk\src/w32fns.c:7717 c:\emacs\trunk\src/w32fns.c:7749 c:\emacs\trunk\src/emacs.c:345 c:\emacs\trunk\src/alloc.c:6440 c:\emacs\trunk\src/fileio.c:5380 c:\emacs\trunk\src/emacs.c:1941 c:\emacs\trunk\src/emacs.c:329 c:\emacs\trunk\src/alloc.c:6440 c:\emacs\trunk\src/xdisp.c:13909 c:\emacs\trunk\src/xdisp.c:13491 c:\emacs\trunk\src/xdisp.c:12691 c:\emacs\trunk\src/keyboard.c:2428 c:\emacs\trunk\src/keyboard.c:9223 c:\emacs\trunk\src/keyboard.c:1458 c:\emacs\trunk\src/eval.c:1288 c:\emacs\trunk\src/keyboard.c:1167 c:\emacs\trunk\src/eval.c:1059 c:\emacs\trunk\src/keyboard.c:1146 c:\emacs\trunk\src/keyboard.c:778 c:\emacs\trunk\src/keyboard.c:842 c:\emacs\trunk\src/emacs.c:1564 crt1.c:0 ??:0 ??:0 ??:0 c:\emacs\trunk\src/w32fns.c:7717 c:\emacs\trunk\src/w32fns.c:7749 c:\emacs\trunk\src/emacs.c:345 c:\emacs\trunk\src/sysdep.c:1638 c:\emacs\trunk\src/sysdep.c:1614 c:\emacs\trunk\src/sysdep.c:1650 crt1.c:0 ??:0 ??:0 ??:0 c:\emacs\trunk\src/w32fns.c:7717 c:\emacs\trunk\src/w32fns.c:7749 c:\emacs\trunk\src/emacs.c:345 c:\emacs\trunk\src/sysdep.c:1638 c:\emacs\trunk\src/sysdep.c:1614 c:\emacs\trunk\src/sysdep.c:1650 crt1.c:0 ??:0 ??:0 ??:0 c:\emacs\trunk\src/w32fns.c:7717 c:\emacs\trunk\src/w32fns.c:7749 c:\emacs\trunk\src/emacs.c:345 c:\emacs\trunk\src/alloc.c:6440 c:\emacs\trunk\src/fileio.c:5380 c:\emacs\trunk\src/emacs.c:1941 c:\emacs\trunk\src/emacs.c:329 c:\emacs\trunk\src/alloc.c:6440 c:\emacs\trunk\src/textprop.c:467 c:\emacs\trunk\src/textprop.c:1487 c:\emacs\trunk\src/xdisp.c:11613 c:\emacs\trunk\src/xdisp.c:11980 c:\emacs\trunk\src/xdisp.c:16246 c:\emacs\trunk\src/xdisp.c:13932 c:\emacs\trunk\src/eval.c:1326 c:\emacs\trunk\src/xdisp.c:13912 c:\emacs\trunk\src/xdisp.c:13491 c:\emacs\trunk\src/xdisp.c:12691 c:\emacs\trunk\src/keyboard.c:2428 c:\emacs\trunk\src/keyboard.c:9223 c:\emacs\trunk\src/keyboard.c:1458 c:\emacs\trunk\src/eval.c:1288 c:\emacs\trunk\src/keyboard.c:1167 c:\emacs\trunk\src/eval.c:1059 c:\emacs\trunk\src/keyboard.c:1146 c:\emacs\trunk\src/keyboard.c:778 c:\emacs\trunk\src/keyboard.c:842 c:\emacs\trunk\src/emacs.c:1564 crt1.c:0 ??:0 ??:0 ??:0 c:\emacs\trunk\src/w32fns.c:7717 c:\emacs\trunk\src/w32fns.c:7749 c:\emacs\trunk\src/emacs.c:345 c:\emacs\trunk\src/alloc.c:6440 c:\emacs\trunk\src/dispnew.c:1257 c:\emacs\trunk\src/dispnew.c:4239 c:\emacs\trunk\src/dispnew.c:3532 c:\emacs\trunk\src/dispnew.c:3284 c:\emacs\trunk\src/dispnew.c:3213 c:\emacs\trunk\src/xdisp.c:13528 c:\emacs\trunk\src/xdisp.c:12691 c:\emacs\trunk\src/keyboard.c:2428 c:\emacs\trunk\src/keyboard.c:9223 c:\emacs\trunk\src/keyboard.c:1458 c:\emacs\trunk\src/eval.c:1288 c:\emacs\trunk\src/keyboard.c:1167 c:\emacs\trunk\src/eval.c:1059 c:\emacs\trunk\src/keyboard.c:1146 c:\emacs\trunk\src/keyboard.c:778 c:\emacs\trunk\src/keyboard.c:842 c:\emacs\trunk\src/emacs.c:1564 crt1.c:0 ??:0 ??:0 ??:0 c:\emacs\trunk\src/w32fns.c:7717 c:\emacs\trunk\src/w32fns.c:7749 c:\emacs\trunk\src/emacs.c:345 c:\emacs\trunk\src/sysdep.c:1638 c:\emacs\trunk\src/sysdep.c:1614 c:\emacs\trunk\src/sysdep.c:1650 crt1.c:0 ??:0 ??:0 ??:0 c:\emacs\trunk\src/w32fns.c:7717 c:\emacs\trunk\src/w32fns.c:7749 c:\emacs\trunk\src/emacs.c:345 c:\emacs\trunk\src/alloc.c:6440 c:\emacs\trunk\src/fontset.c:1999 c:\emacs\trunk\src/eval.c:2777 c:\emacs\trunk\src/bytecode.c:899 c:\emacs\trunk\src/eval.c:3006 c:\emacs\trunk\src/eval.c:2823 c:\emacs\trunk\src/bytecode.c:899 c:\emacs\trunk\src/eval.c:3006 c:\emacs\trunk\src/eval.c:2823 c:\emacs\trunk\src/bytecode.c:899 c:\emacs\trunk\src/eval.c:3006 c:\emacs\trunk\src/eval.c:2823 c:\emacs\trunk\src/bytecode.c:899 c:\emacs\trunk\src/eval.c:3006 c:\emacs\trunk\src/eval.c:2823 c:\emacs\trunk\src/callint.c:852 c:\emacs\trunk\src/eval.c:2781 c:\emacs\trunk\src/eval.c:2599 c:\emacs\trunk\src/keyboard.c:10233 c:\emacs\trunk\src/keyboard.c:1586 c:\emacs\trunk\src/eval.c:1288 c:\emacs\trunk\src/keyboard.c:1167 c:\emacs\trunk\src/eval.c:1059 c:\emacs\trunk\src/keyboard.c:1146 c:\emacs\trunk\src/keyboard.c:778 c:\emacs\trunk\src/keyboard.c:842 c:\emacs\trunk\src/emacs.c:1564 crt1.c:0 ??:0 ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written 2012-11-20 19:15 ` Dani Moncayo @ 2012-11-20 19:41 ` Eli Zaretskii 2012-11-20 20:11 ` Dani Moncayo 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-11-20 19:41 UTC (permalink / raw) To: Dani Moncayo; +Cc: lekktu, 12911 > Date: Tue, 20 Nov 2012 20:15:10 +0100 > From: Dani Moncayo <dmoncayo@gmail.com> > Cc: Drew Adams <drew.adams@oracle.com>, lekktu@gmail.com, monnier@iro.umontreal.ca, > 12911@debbugs.gnu.org > > > Dani, where can I find the binary which fits this: > > (I've caught this by chance - I was not in the "to" or the "cc") ??? Of course you were in "To", take another look. > You can get the binary from > https://www.dropbox.com/sh/7jr3vbv9tm1zod0/jPuvfrJAe8 Thanks. > > Or maybe you (Dani) can run addr2line on that binary and tell what you > > get from Drew's backtraces. > > I'm never done that, but I've tried it: > addr2line -e emacs.exe < bt-in.txt > bt-out.txt > > where the "emacs.exe" is the one from the build used by Drew. I'm > attaching both files. Thanks. Drew, you really should report these, and try cooperating in the resolution of these problems. There are at least 2 crashes here that I never saw. > c:\emacs\trunk\src/w32fns.c:7717 > c:\emacs\trunk\src/w32fns.c:7749 > c:\emacs\trunk\src/emacs.c:345 > c:\emacs\trunk\src/alloc.c:6440 > c:\emacs\trunk\src/xdisp.c:13540 This is assertion violation in redisplay_internal, here: eassert (EQ (XFRAME (selected_frame)->selected_window, selected_window)); This crash is probably of the kind you reported in the past, related to the selected-frame/selected-window issues. > c:\emacs\trunk\src/w32fns.c:7717 > c:\emacs\trunk\src/w32fns.c:7749 > c:\emacs\trunk\src/emacs.c:345 > c:\emacs\trunk\src/alloc.c:6440 > c:\emacs\trunk\src/fileio.c:5380 This is a crash in auto-save, which I never saw before: for (do_handled_files = 0; do_handled_files < 2; do_handled_files++) for (tail = Vbuffer_alist; CONSP (tail); tail = XCDR (tail)) { buf = XCDR (XCAR (tail)); b = XBUFFER (buf); <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > c:\emacs\trunk\src/w32fns.c:7717 > c:\emacs\trunk\src/w32fns.c:7749 > c:\emacs\trunk\src/emacs.c:345 > c:\emacs\trunk\src/alloc.c:6440 > c:\emacs\trunk\src/dispnew.c:1257 Another assertion violation in redisplay: static bool row_equal_p (struct glyph_row *a, struct glyph_row *b, bool mouse_face_p) { eassert (verify_row_hash (a)); eassert (verify_row_hash (b)); <<<<<<<<<<<<<<<<<<<<<<<<<<<<< > c:\emacs\trunk\src/w32fns.c:7717 > c:\emacs\trunk\src/w32fns.c:7749 > c:\emacs\trunk\src/emacs.c:345 > c:\emacs\trunk\src/alloc.c:6440 > c:\emacs\trunk\src/fontset.c:1999 This crash is in fontset-info: /* Then store opened font names to cdr of each elements. */ for (i = 0; ! NILP (realized[k][i]); i++) { if (c <= MAX_5_BYTE_CHAR) val = FONTSET_REF (realized[k][i], c); else val = FONTSET_FALLBACK (realized[k][i]); if (! CONSP (val) || ! VECTORP (XCDR (val))) continue; /* VAL: (int . [[FACE-ID FONT-DEF FONT-OBJECT int] ... ]) */ val = XCDR (val); for (j = 0; j < ASIZE (val); j++) { elt = AREF (val, j); if (FONT_OBJECT_P (RFONT_DEF_OBJECT (elt))) <<<<<<<<< I don't think I've ever heard about such crashes. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written 2012-11-20 19:41 ` Eli Zaretskii @ 2012-11-20 20:11 ` Dani Moncayo 0 siblings, 0 replies; 59+ messages in thread From: Dani Moncayo @ 2012-11-20 20:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, 12911 >> > Dani, where can I find the binary which fits this: >> >> (I've caught this by chance - I was not in the "to" or the "cc") > > ??? Of course you were in "To", take another look. Brain fart, sorry. -- Dani Moncayo ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-20 16:36 ` Juanma Barranquero 2012-11-20 17:11 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files " Drew Adams @ 2012-11-20 17:49 ` Eli Zaretskii 1 sibling, 0 replies; 59+ messages in thread From: Eli Zaretskii @ 2012-11-20 17:49 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 12911 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Tue, 20 Nov 2012 17:36:50 +0100 > Cc: Eli Zaretskii <eliz@gnu.org>, 12911@debbugs.gnu.org > > It's not as if the user is going to get backtraces all over his hard > disk on every single run. "All over the hard disk" will almost never happen, because people who invoke Emacs from a desktop icon will always have Emacs run in the same directory. All the backtraces will be on a single file in that directory. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12908: 24.3.50; file `emacs_backtrace.txt'? @ 2012-11-16 18:30 Drew Adams 2012-11-17 18:45 ` Paul Eggert 0 siblings, 1 reply; 59+ messages in thread From: Drew Adams @ 2012-11-16 18:30 UTC (permalink / raw) To: 12908 Still getting many crashes (every session), but now I notice that Emacs is creating a file `emacs_backtrace.txt' in the current directory (or perhaps it is in the dir in which Emacs was started?). I looked in the Emacs manual, the Elisp manual, and NEWS for some information about this file, but found nothing (so there is a doc bug, at least). What is the file for, how are users to use it and control whether and where it is written, etc.? Here is the content of one such file, in case it helps in some way (which I doubt): Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x012072B8 0x012080B9 0x0103B54F 0x0104F14B 0x01038878 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x01063E40 0x010030FF 0x01001411 0x01021A07 0x01208B6F 0x01206FA0 0x01203D74 0x0103B556 0x0104F14B 0x01038878 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01144D4F 0x01144D2A 0x01144D83 0x010011E6 0x7C8438F6 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01144D4F 0x01144D2A 0x01144D83 0x010011E6 0x7C8438F6 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x01063E40 0x010030FF 0x01001411 0x01021A07 0x01271987 0x012753CF 0x01201334 0x01202410 0x0121160D 0x01208C14 0x01010FC6 0x01208BA1 0x01206FA0 0x01203D74 0x0103B556 0x0104F14B 0x01038878 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x010EFEEA 0x010F6A68 0x010F5208 0x010F48F4 0x010F4616 0x0120710E 0x01203D74 0x0103B556 0x0104F14B 0x01038878 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01144D4F 0x01144D2A 0x01144D83 0x010011E6 0x7C8438F6 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x012D32D3 0x01014F64 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E6C1C 0x01014FD5 0x01014733 0x01052C55 0x010390C7 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600) of 2012-11-05 on MS-W7-DANI Bzr revision: 110809 lekktu@gmail.com-20121105172930-a5gn0bwi4lndchhw Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.7) --no-opt --enable-checking --cflags -I../../libs/libXpm-3.5.10/include -I../../libs/libXpm-3.5.10/src -I../../libs/libpng-1.2.37-lib/include -I../../libs/zlib-1.2.5 -I../../libs/giflib-4.1.4-1-lib/include -I../../libs/jpeg-6b-4-lib/include -I../../libs/tiff-3.8.2-1-lib/include -I../../libs/libxml2-2.7.8-w32-bin/include/libxml2 -I../../libs/gnutls-3.0.9-w32-bin/include -I../../libs/libiconv-1.9.2-1-lib/include' ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12908: 24.3.50; file `emacs_backtrace.txt'? 2012-11-16 18:30 bug#12908: 24.3.50; file `emacs_backtrace.txt'? Drew Adams @ 2012-11-17 18:45 ` Paul Eggert 2012-11-17 19:09 ` Eli Zaretskii 0 siblings, 1 reply; 59+ messages in thread From: Paul Eggert @ 2012-11-17 18:45 UTC (permalink / raw) To: 12908 There seems to be some misunderstanding here. The Unix code does not write into $HOME/backtrace.txt, or into $HOME, or into anywhere like that. It writes to stderr. The programs that invoke Emacs (normally window managers) arrange for the standard error stream to be sent to a suitable place. The Microsoft Windows code does something different: it writes the backtrace both to stderr and to a file emacs_backtrace.txt. If the goal is to mimic the Unix behavior as closely as possible, then the fix should be simple: output the backtrace just to stderr, as the Unix code does. Perhaps there are reasons not to do that on Microsoft Windows, but as these reasons are specific to that platform it would seem that any fix would be platform-specific as well. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12908: 24.3.50; file `emacs_backtrace.txt'? 2012-11-17 18:45 ` Paul Eggert @ 2012-11-17 19:09 ` Eli Zaretskii 2012-11-17 19:29 ` Paul Eggert 2012-11-17 23:01 ` bug#12908: 24.3.50; file `emacs_backtrace.txt'? Drew Adams 0 siblings, 2 replies; 59+ messages in thread From: Eli Zaretskii @ 2012-11-17 19:09 UTC (permalink / raw) To: Paul Eggert; +Cc: 12908 > Date: Sat, 17 Nov 2012 10:45:00 -0800 > From: Paul Eggert <eggert@cs.ucla.edu> > > There seems to be some misunderstanding here. The Unix code does > not write into $HOME/backtrace.txt, or into $HOME, or into anywhere > like that. It writes to stderr. The programs that invoke Emacs > (normally window managers) arrange for the standard error stream > to be sent to a suitable place. That suitable place is in a subdirectory of the user's home directory, at least on the most popular systems, according to the Emacs manual. > The Microsoft Windows code does something different: it writes the > backtrace both to stderr and to a file emacs_backtrace.txt. Yes. > If the goal is to mimic the Unix behavior as closely as possible, then > the fix should be simple: output the backtrace just to stderr, as > the Unix code does. This will not work: unlike Unix, a GUI program invoked on Windows from a desktop icon normally has its standard error stream closed. So writing there will end up nowhere. That is why my implementation writes both to stderr and to the file; in the worst (or best?) case, you have two copies of the information, but you always have at least one. > Perhaps there are reasons not to do that on Microsoft Windows, but > as these reasons are specific to that platform it would seem that > any fix would be platform-specific as well. I don't see it that way. If what the Unix code writes to stderr ends up in some random location under the user's home directory, or even in a place whose whereabouts no one knows, then I see no reason not to write it on Windows in the current directory of the Emacs process. (Note that unlike on Unix, Emacs on Windows doesn't change its current directory from where it was started, so the backtrace will normally end up in the same directory for all invocations of Emacs on that machine by that user.) If we want the information in .emacs.d, we need to actively write it there on Unix. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12908: 24.3.50; file `emacs_backtrace.txt'? 2012-11-17 19:09 ` Eli Zaretskii @ 2012-11-17 19:29 ` Paul Eggert 2012-11-17 19:42 ` Eli Zaretskii 2012-11-17 23:01 ` bug#12908: 24.3.50; file `emacs_backtrace.txt'? Drew Adams 1 sibling, 1 reply; 59+ messages in thread From: Paul Eggert @ 2012-11-17 19:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12908 On 11/17/2012 11:09 AM, Eli Zaretskii wrote: > That suitable place is in a subdirectory of the user's home directory, > at least on the most popular systems, according to the Emacs manual. Sure, but it's under the user's control, and it's easy to change the default. I'm not a typical user, but I'd guess that about half the time I put stderr some place other than the default, because I start up Emacs from a terminal session or suchlike. And when Emacs is being debugged, stderr is almost never put into a home-directory file. > unlike Unix, a GUI program invoked on Windows > from a desktop icon normally has its standard error stream closed. This is a problem not just for backtraces, but for everything that Emacs sends to stderr. Perhaps it would be better for Emacs, on Microsoft Windows, to redirect stderr to a file, so that the information does not get lost. That file would serve the function that emacs_backtrace.txt serves now, but it would also capture all the other stuff that goes to stderr and currently gets lost. Even if we continue to restrict the contents of the file to backtraces, the name of this file is something that is specific to the Microsoft Windows version of Emacs, so the GNU and Unix versions don't have to worry about the file's name. > (Note that unlike on Unix, Emacs on Windows doesn't change its current > directory from where it was started No, Emacs is the same on both platforms. The main Emacs process doesn't invoke chdir on GNU or Unix either, unless you use the --chdir option. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12908: 24.3.50; file `emacs_backtrace.txt'? 2012-11-17 19:29 ` Paul Eggert @ 2012-11-17 19:42 ` Eli Zaretskii 2012-11-17 21:25 ` Paul Eggert 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-11-17 19:42 UTC (permalink / raw) To: Paul Eggert; +Cc: 12908 > Date: Sat, 17 Nov 2012 11:29:47 -0800 > From: Paul Eggert <eggert@cs.ucla.edu> > CC: 12908@debbugs.gnu.org > > On 11/17/2012 11:09 AM, Eli Zaretskii wrote: > > > That suitable place is in a subdirectory of the user's home directory, > > at least on the most popular systems, according to the Emacs manual. > > Sure, but it's under the user's control, and it's easy to > change the default. Unless we are going to ask each Emacs user to change the default so that the file ends up in .emacs.d, we still have a discrepancy vs what Stefan asked to do. > > unlike Unix, a GUI program invoked on Windows > > from a desktop icon normally has its standard error stream closed. > > This is a problem not just for backtraces, but for everything that > Emacs sends to stderr. Which is nothing on Windows, except in debug builds with non-default options turned on, which are used only by experts (who know how not to lose this stuff). > Perhaps it would be better for Emacs, on Microsoft Windows, to > redirect stderr to a file, so that the information does not get > lost. It's not easy to do that, and it isn't worth the trouble, see above. But if someone volunteers to do that, my hat's off. Until then, we cannot safely use stderr on Windows for information we cannot afford losing. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12908: 24.3.50; file `emacs_backtrace.txt'? 2012-11-17 19:42 ` Eli Zaretskii @ 2012-11-17 21:25 ` Paul Eggert 2012-11-18 4:04 ` Eli Zaretskii 0 siblings, 1 reply; 59+ messages in thread From: Paul Eggert @ 2012-11-17 21:25 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12908 On 11/17/2012 11:42 AM, Eli Zaretskii wrote: > Unless we are going to ask each Emacs user to change the default so > that the file ends up in .emacs.d, we still have a discrepancy vs what > Stefan asked to do. I must have missed that request; all I see from him in Bug#12908 is a comment about how to deal with the file names under the assumption that Emacs itself redirects stderr to a file whose name Emacs chooses. That assumption is currently true on Microsoft Windows for backtraces, but it's not true for GNU and Unix where we don't have the problem. >> Perhaps it would be better for Emacs, on Microsoft Windows, to >> redirect stderr to a file, so that the information does not get >> lost. > > It's not easy to do that Can Emacs use freopen? For example, the following code would do the job on a POSIX platform: if stderr is closed, it redirects it to emacs-stderr.txt in the current directory, if possible. Would this sort of thing work on Microsoft platform? === modified file 'src/emacs.c' --- src/emacs.c 2012-11-08 19:12:23 +0000 +++ src/emacs.c 2012-11-17 21:23:46 +0000 @@ -748,6 +748,11 @@ main (int argc, char **argv) unexec_init_emacs_zone (); #endif +#ifdef DOS_NT + if (dup2 (STDERR_FILENO, STDERR_FILENO) < 0) + ignore_value (freopen ("emacs-stderr.txt", "a", stderr)); +#endif + atexit (close_output_streams); sort_args (argc, argv); ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12908: 24.3.50; file `emacs_backtrace.txt'? 2012-11-17 21:25 ` Paul Eggert @ 2012-11-18 4:04 ` Eli Zaretskii 2012-11-18 5:19 ` Paul Eggert 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-11-18 4:04 UTC (permalink / raw) To: Paul Eggert; +Cc: 12908 > Date: Sat, 17 Nov 2012 13:25:17 -0800 > From: Paul Eggert <eggert@cs.ucla.edu> > CC: 12908@debbugs.gnu.org > > >> Perhaps it would be better for Emacs, on Microsoft Windows, to > >> redirect stderr to a file, so that the information does not get > >> lost. > > > > It's not easy to do that > > Can Emacs use freopen? That's not the problem. The problem is that stderr is used when Emacs is run in non-interactive mode, and should not be touched then. The problem is in detecting when stderr is closed or an invalid handle to begin with, and do the redirection only then. In all my readings and tests, I was unable to find a reliable, let alone documented, way of determining that. I don't even know if the "invalid handle" (which is a pointer on Windows) is NULL or an INVALID_HANDLE_VALUE. > For example, the following code would do the job on a POSIX > platform: if stderr is closed, it redirects it to emacs-stderr.txt > in the current directory, if possible. Would this sort of thing > work on Microsoft platform? It will surely break -batch. And guess what happens with this redirection when Emacs has its stderr closed or invalid in the first place. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12908: 24.3.50; file `emacs_backtrace.txt'? 2012-11-18 4:04 ` Eli Zaretskii @ 2012-11-18 5:19 ` Paul Eggert 2012-11-18 17:16 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Eli Zaretskii 0 siblings, 1 reply; 59+ messages in thread From: Paul Eggert @ 2012-11-18 5:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12908 On 11/17/2012 08:04 PM, Eli Zaretskii wrote: > The > problem is in detecting when stderr is closed or an invalid handle to > begin with, and do the redirection only then. In all my readings and > tests, I was unable to find a reliable, let alone documented, way of > determining that. The method I gave in <http://bugs.gnu.org/12908#73> is portable to GNU and POSIXish hosts, where you can test whether a file descriptor FD is valid by invoking dup2 (FD, FD). Gnulib has a dup2 implementation that works on Microsoft Windows, so if we use that, it seems we should be able to use the same idea there too. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-18 5:19 ` Paul Eggert @ 2012-11-18 17:16 ` Eli Zaretskii 2012-11-18 19:18 ` Paul Eggert 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-11-18 17:16 UTC (permalink / raw) To: Paul Eggert; +Cc: 12911 > Date: Sat, 17 Nov 2012 21:19:36 -0800 > From: Paul Eggert <eggert@cs.ucla.edu> > CC: 12908@debbugs.gnu.org > > Gnulib has a dup2 implementation that works on Microsoft Windows, > so if we use that, it seems we should be able to use the same idea > there too. Thanks, but no, thanks. Gnulib's dup2 implementation uses so many non-trivial interfaces (exceptions, invalid parameter handlers, etc.) that I'd prefer not to deal with for a feature that needs to be rock solid and dependable. In any case, this is an almost orthogonal issue to what is being discussed here. The issue here is not _whether_ to redirect stderr, but rather _where_to_ to redirect it. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-18 17:16 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Eli Zaretskii @ 2012-11-18 19:18 ` Paul Eggert 2012-11-18 21:10 ` Eli Zaretskii 0 siblings, 1 reply; 59+ messages in thread From: Paul Eggert @ 2012-11-18 19:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12911 On 11/18/2012 09:16 AM, Eli Zaretskii wrote: > The issue here is not _whether_ to redirect stderr, > but rather _where_to_ to redirect it. On GNU and Unix hosts, there's no issue. stderr should not be redirected. It never has been redirected, and there's no reason to change. > ... putting that file in ~/.emacs.d/ (also in the home a > directory, so maybe you will still protest) is slightly better. > But if Emacs should do that, it should do it on all the supported > platforms. There's no reason for Emacs to change its behavior on GNUish hosts. People on these hosts are used to the current behavior with stderr. Any problems in this area are limited to Microsoft platforms, and can be solved in a Microsoft-specific way. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-18 19:18 ` Paul Eggert @ 2012-11-18 21:10 ` Eli Zaretskii 2012-11-19 1:44 ` Stefan Monnier 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-11-18 21:10 UTC (permalink / raw) To: Paul Eggert; +Cc: 12911-done > Date: Sun, 18 Nov 2012 11:18:29 -0800 > From: Paul Eggert <eggert@cs.ucla.edu> > CC: 12911@debbugs.gnu.org > > There's no reason for Emacs to change its behavior > on GNUish hosts. People on these hosts are used to > the current behavior with stderr. Any problems > in this area are limited to Microsoft platforms, and > can be solved in a Microsoft-specific way. There are no problems on Windows, either. Bug closed. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-18 21:10 ` Eli Zaretskii @ 2012-11-19 1:44 ` Stefan Monnier 2012-11-19 3:50 ` Eli Zaretskii 0 siblings, 1 reply; 59+ messages in thread From: Stefan Monnier @ 2012-11-19 1:44 UTC (permalink / raw) To: 12911 >> There's no reason for Emacs to change its behavior >> on GNUish hosts. People on these hosts are used to >> the current behavior with stderr. Any problems >> in this area are limited to Microsoft platforms, and >> can be solved in a Microsoft-specific way. > There are no problems on Windows, either. There's clearly a problem: creating a file emacs_backtrace.txt in some "in your face" directory annoys some users (and I'm sure we can come up with funny hypothetical scenarios where it leads to serious breakage of god knows what). Hence the suggestion to use ~/.emacs.d which is much less "in your face" and much safer. Stefan "Boy do I wish we never moved away from plain macros" ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-19 1:44 ` Stefan Monnier @ 2012-11-19 3:50 ` Eli Zaretskii 0 siblings, 0 replies; 59+ messages in thread From: Eli Zaretskii @ 2012-11-19 3:50 UTC (permalink / raw) To: Stefan Monnier; +Cc: 12911 > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: eliz@gnu.org, drew.adams@oracle.com > Date: Sun, 18 Nov 2012 20:44:23 -0500 > > >> There's no reason for Emacs to change its behavior > >> on GNUish hosts. People on these hosts are used to > >> the current behavior with stderr. Any problems > >> in this area are limited to Microsoft platforms, and > >> can be solved in a Microsoft-specific way. > > There are no problems on Windows, either. > > There's clearly a problem: creating a file emacs_backtrace.txt in some > "in your face" directory annoys some users (and I'm sure we can come up > with funny hypothetical scenarios where it leads to serious breakage of > god knows what). > Hence the suggestion to use ~/.emacs.d which is much less "in your face" > and much safer. I'm waiting for this to be implemented on Posix platforms, then. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12908: 24.3.50; file `emacs_backtrace.txt'? 2012-11-17 19:09 ` Eli Zaretskii 2012-11-17 19:29 ` Paul Eggert @ 2012-11-17 23:01 ` Drew Adams 2012-11-18 3:58 ` Eli Zaretskii 1 sibling, 1 reply; 59+ messages in thread From: Drew Adams @ 2012-11-17 23:01 UTC (permalink / raw) To: 'Eli Zaretskii', 'Paul Eggert'; +Cc: 12908 (I see that everyone is using the original bug thread, even though I created a new one at Eli's request, and the original one was supposedly closed (doc fixed).) > (Note that unlike on Unix, Emacs on Windows doesn't change its current > directory from where it was started, so the backtrace will normally > end up in the same directory for all invocations of Emacs on that > machine by that user.) > > If we want the information in .emacs.d, we need to actively write it > there on Unix. On Windows, I believe that some (many? most?) users start Emacs from a shortcut, and that some (many? most?) of those start it in a directory that has meaning for them, e.g., a directory of user files. (I, for example, start it in a directory of my Emacs Lisp files, and I open it with Dired there.) Is the situation similar on Unix? Do users often start Emacs in a user directory? It's one thing to stick the backtrace file in the startup directory if that is the default Emacs bin directory or some such Emacs-related folder. It's another thing to stick the file in a user directory because the user intentionally starts Emacs there. That has been my point from the beginning: I don't really care where you stick it, as long as it is in some Emacs/system internal program folder and not a user folder. There is a reason why programs on Windows are often installed (and started) in an application-specific folder under `Program Files', and not in any old user folder. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12908: 24.3.50; file `emacs_backtrace.txt'? 2012-11-17 23:01 ` bug#12908: 24.3.50; file `emacs_backtrace.txt'? Drew Adams @ 2012-11-18 3:58 ` Eli Zaretskii 2012-11-18 4:40 ` Drew Adams 2012-11-18 5:19 ` bug#12908: 24.3.50; file `emacs_backtrace.txt'? Paul Eggert 0 siblings, 2 replies; 59+ messages in thread From: Eli Zaretskii @ 2012-11-18 3:58 UTC (permalink / raw) To: Drew Adams; +Cc: eggert, 12908 > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <12908@debbugs.gnu.org> > Date: Sat, 17 Nov 2012 15:01:40 -0800 > > That has been my point from the beginning: I don't really care where > you stick it, as long as it is in some Emacs/system internal program > folder and not a user folder. On Unix, the data winds up in some directory under user's home directory. See the manual. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12908: 24.3.50; file `emacs_backtrace.txt'? 2012-11-18 3:58 ` Eli Zaretskii @ 2012-11-18 4:40 ` Drew Adams 2012-11-18 17:53 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Eli Zaretskii 2012-11-18 5:19 ` bug#12908: 24.3.50; file `emacs_backtrace.txt'? Paul Eggert 1 sibling, 1 reply; 59+ messages in thread From: Drew Adams @ 2012-11-18 4:40 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: eggert, 12908 > > That has been my point from the beginning: I don't really care where > > you stick it, as long as it is in some Emacs/system internal program > > folder and not a user folder. > > On Unix, the data winds up in some directory under user's home > directory. See the manual. I don't care what Emacs does on Unix or on Windows. Or on Peanut Butter. See the manual - sheesh. If Emacs on Unix is just as user-inconsiderate in this regard as it is on Windows, then it too needs to be sent back for regrooving. My point is the same: Please do not plop such a file into a user folder. On any platform. It does not belong there. I just happen to be using Emacs on Windows, and I reported this problem there. If it is not Windows-specific, fine - please fix it wherever it occurs. You are discussing implementation and platforms, as well you should, no doubt. But my concern is at the user level. Please don't mess with user data. That's not nice. And this includes user folders containing user files. I really don't care about the finger-pointing. You apparently claim that there is as much of this problem on Unix as on Windows. Some others seem to disagree (though that's not too clear to me). That does not matter to me. If there is a problem on platform XYZ, please fix it on XYZ. For all XYZ, preferably. For Windows, at least. It does not sound like a great argument to say that this will not be fixed on Windows until someone agrees to fix it on Unix also. Especially if those who would presumably be the ones to fix it on Unix do not seem to agree that it is a problem on Unix (again, I'm not sure that's what the claim is). IOW, here we go 'round & 'round again. Musical chairs with a bit of blame game thrown in, it seems. I hope the bug gets fixed. On Windows, at least, this is a regression: Users have never before had to put up with this Emacs pollution of user folders. Introducing a regression and then classifying it as `wont-fix' is disingenuous. Please just restore the state before the regression if you cannot find a good way to fix the bug and still get the backtrace info you want. Restore the sane state while you go on to discuss possible ways to deal with the problem in a ideal way. If you never find that ideal way, then leave things as they were before. I really do not agree with freewheeling introduction of "improvements" that are accompanied by regressions or other negative behavior that is then classified as `wont-fix'. Be less interested in your creative development than in the possible harm/annoyance to users of its side effects. The first rule should be not to do any harm. The second rule should be that if you accidentally do some harm while trying to improve something, then undo the harm. We have users jump through 39 questions/confirmations just to send a bug-report message or exit without saving a buffer. Nice and careful, respectful of user wishes. And yet here we are now writing crap to user folders without so much as a "Do you really want to...?" - or even a "Hey, I just wrote some crap to your folder XYZ - sorry about that!" ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-18 4:40 ` Drew Adams @ 2012-11-18 17:53 ` Eli Zaretskii 2012-11-18 18:42 ` Drew Adams 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2012-11-18 17:53 UTC (permalink / raw) To: Drew Adams; +Cc: eggert, 12911 > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <eggert@cs.ucla.edu>, <12908@debbugs.gnu.org> > Date: Sat, 17 Nov 2012 20:40:08 -0800 > > I don't care what Emacs does on Unix or on Windows. Well, I do. Which is why I'm working on developing and maintaining Emacs. And if you think that declaring your indifference to the cross-platform compatibility of Emacs raises the value of your arguments in my eyes, then I suggest that you reconsider. > my concern is at the user level. Please don't mess with user data. That's > not nice. And this includes user folders containing user files. Any folder on Windows can contain user data, because most Windows users are usually local administrators and have almost unlimited privileges (except perhaps on corporate servers). In fact, Windows doesn't even have a firm notion of a home directory. There are guidelines where _applications_ should put their files, but nothing about what is "home" for the user, where the user should keep her precious lasagna recipes. We (Emacs) pick up one or 2 plausible locations and pretend they are that "home", but they aren't, as far as the OS and the rest of applications are concerned. They are just more or less random directories. > The first rule should be not to do any harm. You are making a mount out of a molehill. There is no harm. Well-behaving applications write to all kinds of directories all the time, including user home directories. Bash writes ~/.bash_history, Bazaar writes ~/.bzr.log, Eshell writes ~/.eshell/*. Etc. etc. -- this is the norm, not the exception. Emacs behaves according to well-established norms. I agree that putting that file in ~/.emacs.d/ (also in the home a directory, so maybe you will still protest) is slightly better. But if Emacs should do that, it should do it on all the supported platforms. I'm sorry, but unless this is what's agreed soon, I _will_ close this bug. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-18 17:53 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Eli Zaretskii @ 2012-11-18 18:42 ` Drew Adams 0 siblings, 0 replies; 59+ messages in thread From: Drew Adams @ 2012-11-18 18:42 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: eggert, 12911 > > I don't care what Emacs does on Unix or on Windows. > > Well, I do. Which is why I'm working on developing and maintaining > Emacs. Read my statement in context. Taking it out of context reverses the intended meaning. > And if you think that declaring your indifference to the > cross-platform compatibility of Emacs I did no such thing. I am not at all indifferent to cross-platform compatibility. As you know full well. > raises the value of your arguments in my eyes, then I > suggest that you reconsider. > > > my concern is at the user level. Please don't mess with > > user data. That's not nice. And this includes user folders > > containing user files. > > Any folder on Windows can contain user data, because most Windows > users are usually local administrators and have almost unlimited > privileges (except perhaps on corporate servers). Don't make the perfect the enemy of the good. You are stretching things. Yes, what you say is true. No, it is not particularly relevant. Yes, my entire C:/ drive is my drive and my data. So what? Irrelevant to the discussion. Please stick to the particulars. > In fact, Windows > doesn't even have a firm notion of a home directory. There are > guidelines where _applications_ should put their files, but nothing > about what is "home" for the user, where the user should keep her > precious lasagna recipes. We (Emacs) pick up one or 2 plausible > locations and pretend they are that "home", but they aren't, as far as > the OS and the rest of applications are concerned. They are just more > or less random directories. I have no argument with any of what you said there. > > The first rule should be not to do any harm. > > You are making a mount out of a molehill. There is no harm. > Well-behaving applications write to all kinds of directories all the > time, including user home directories. Bash writes ~/.bash_history, > Bazaar writes ~/.bzr.log, Eshell writes ~/.eshell/*. Etc. etc. -- > this is the norm, not the exception. Emacs behaves according to > well-established norms. > > I agree that putting that file in ~/.emacs.d/ (also in the home a > directory, so maybe you will still protest) is slightly better. Why would I protest? I'm the one who _suggested_ putting it there. And I have not once mentioned "home" directory in this discussion. Perhaps you are confusing me with someone else. Anyway, I'm very glad you agree about ~/.emacs.d/. So at the very least this bug should remain open on the wishlist until fixed. To me, this bother is a regression, as I said earlier. But whether you look at it like that or not, at least you agree that it is better to put the file in ~/.emacs.d/. That's progress. > But if Emacs should do that, it should do it on all the > supported platforms. I'm sorry, but unless this is what's > agreed soon, I _will_ close this bug. I have no problem with the bug being fixed on all platforms. In fact, I have explicitly said (several times now) that if this is also a problem on other platforms then it _should_ be fixed there as well. And in the very mail which you quoted out of context above, reversing the sense of what I wrote! This is what I said: If Emacs on Unix is just as user-inconsiderate in this regard as it is on Windows, then it too needs to be sent back for regrooving. And: On any platform. It does not belong there. I just happen to be using Emacs on Windows, and I reported this problem there. If it is not Windows-specific, fine - please fix it wherever it occurs. Pretty damn clear, no? And this: If there is a problem on platform XYZ, please fix it on XYZ. For all XYZ, preferably. For Windows, at least. Is this problem a mountain or a mole hill? Closer to the latter, clearly. But Emacs users never had this bother before. Why should they have it now? Just because on MS Windows everything belongs to the user is no excuse to start polluting arbitrary folders. Such an argument is way off-base. A family who does not (or even cannot) lock their front door is not _asking_ you to come in and trash their house. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12908: 24.3.50; file `emacs_backtrace.txt'? 2012-11-18 3:58 ` Eli Zaretskii 2012-11-18 4:40 ` Drew Adams @ 2012-11-18 5:19 ` Paul Eggert 2012-11-18 17:08 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Eli Zaretskii 1 sibling, 1 reply; 59+ messages in thread From: Paul Eggert @ 2012-11-18 5:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 12908 On 11/17/2012 07:58 PM, Eli Zaretskii wrote: > On Unix, the data winds up in some directory under user's home > directory. No, on Unix that data is sent to the standard error stream. This is documented in the manual. It's common that stderr is redirected to a file, but it's also common that it's not. Traditionally it's not, and many people commonly run Emacs that way. ^ permalink raw reply [flat|nested] 59+ messages in thread
* bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written 2012-11-18 5:19 ` bug#12908: 24.3.50; file `emacs_backtrace.txt'? Paul Eggert @ 2012-11-18 17:08 ` Eli Zaretskii 0 siblings, 0 replies; 59+ messages in thread From: Eli Zaretskii @ 2012-11-18 17:08 UTC (permalink / raw) To: Paul Eggert; +Cc: 12911 > On 11/17/2012 07:58 PM, Eli Zaretskii wrote: > > On Unix, the data winds up in some directory under user's home > > directory. > > No, on Unix that data is sent to the standard error stream. > This is documented in the manual. For the record, here's what the manual says: Emacs is not supposed to crash, but if it does, it produces a "crash report" prior to exiting. The crash report is printed to the standard error stream. If Emacs was started from a graphical desktop on a GNU or Unix system, the standard error stream is commonly redirected to a file such as `~/.xsession-errors', so you can look for the crash report there. On MS-Windows, the crash report is written to a file named `emacs_backtrace.txt' in the current directory of the Emacs process, in addition to the standard error stream. > It's common that stderr is redirected to a file, > but it's also common that it's not. Traditionally > it's not, and many people commonly run Emacs that way. Nowadays, tradition is shifting towards GUI invocation, so stderr will be redirected more often than not. ^ permalink raw reply [flat|nested] 59+ messages in thread
end of thread, other threads:[~2012-11-21 18:42 UTC | newest] Thread overview: 59+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-11-16 20:48 bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Drew Adams 2012-11-16 21:05 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files " Drew Adams 2012-11-16 21:19 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files " Stefan Monnier 2012-11-17 7:26 ` Eli Zaretskii 2012-11-17 17:38 ` Drew Adams 2012-11-17 17:55 ` Eli Zaretskii 2012-11-17 18:24 ` Drew Adams 2012-11-19 1:52 ` Stefan Monnier 2012-11-19 3:51 ` Eli Zaretskii 2012-11-19 4:07 ` Stefan Monnier 2012-11-19 15:52 ` Eli Zaretskii 2012-11-19 18:04 ` Stefan Monnier 2012-11-19 18:13 ` Eli Zaretskii 2012-11-19 18:35 ` Stefan Monnier 2012-11-19 18:40 ` Eli Zaretskii 2012-11-19 19:47 ` Stefan Monnier 2012-11-19 20:05 ` Eli Zaretskii 2012-11-19 21:15 ` Stefan Monnier 2012-11-20 3:58 ` Eli Zaretskii 2012-11-20 4:59 ` Stefan Monnier 2012-11-20 5:02 ` Daniel Colascione 2012-11-20 13:16 ` Andy Moreton 2012-11-20 16:27 ` Eli Zaretskii 2012-11-20 17:03 ` Eli Zaretskii 2012-11-20 17:36 ` Daniel Colascione 2012-11-20 18:02 ` Eli Zaretskii 2012-11-20 18:57 ` bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' " Drew Adams 2012-11-20 19:58 ` Eli Zaretskii 2012-11-20 21:47 ` Drew Adams 2012-11-21 3:47 ` Eli Zaretskii 2012-11-21 4:03 ` Daniel Colascione 2012-11-21 15:43 ` Juanma Barranquero 2012-11-21 16:24 ` bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' filesare written Drew Adams [not found] ` <E86D7DFBD2BD4C3394E5316EF0321A! 95@us.oracle.com> 2012-11-21 16:45 ` Juanma Barranquero 2012-11-21 17:40 ` Drew Adams 2012-11-21 17:43 ` Juanma Barranquero 2012-11-21 18:01 ` Drew Adams 2012-11-21 18:13 ` Juanma Barranquero 2012-11-21 18:42 ` Drew Adams 2012-11-20 18:30 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Stefan Monnier 2012-11-20 18:37 ` Eli Zaretskii 2012-11-20 20:15 ` Stefan Monnier 2012-11-20 16:36 ` Juanma Barranquero 2012-11-20 17:11 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files " Drew Adams 2012-11-20 17:53 ` Eli Zaretskii 2012-11-20 18:10 ` Drew Adams 2012-11-20 18:27 ` Eli Zaretskii 2012-11-20 19:15 ` Dani Moncayo 2012-11-20 19:41 ` Eli Zaretskii 2012-11-20 20:11 ` Dani Moncayo 2012-11-20 17:49 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files " Eli Zaretskii -- strict thread matches above, loose matches on Subject: below -- 2012-11-16 18:30 bug#12908: 24.3.50; file `emacs_backtrace.txt'? Drew Adams 2012-11-17 18:45 ` Paul Eggert 2012-11-17 19:09 ` Eli Zaretskii 2012-11-17 19:29 ` Paul Eggert 2012-11-17 19:42 ` Eli Zaretskii 2012-11-17 21:25 ` Paul Eggert 2012-11-18 4:04 ` Eli Zaretskii 2012-11-18 5:19 ` Paul Eggert 2012-11-18 17:16 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Eli Zaretskii 2012-11-18 19:18 ` Paul Eggert 2012-11-18 21:10 ` Eli Zaretskii 2012-11-19 1:44 ` Stefan Monnier 2012-11-19 3:50 ` Eli Zaretskii 2012-11-17 23:01 ` bug#12908: 24.3.50; file `emacs_backtrace.txt'? Drew Adams 2012-11-18 3:58 ` Eli Zaretskii 2012-11-18 4:40 ` Drew Adams 2012-11-18 17:53 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Eli Zaretskii 2012-11-18 18:42 ` Drew Adams 2012-11-18 5:19 ` bug#12908: 24.3.50; file `emacs_backtrace.txt'? Paul Eggert 2012-11-18 17:08 ` bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).