On 7/17/2022 12:35 PM, Brian Inglis wrote:
On 2022-07-17 08:15, Ken Brown wrote:
On 7/17/2022 7:08 AM, Oleksandr Gavenko wrote:
I saw a new version of emacs-w32 28.1-2 (has 28.1-1) and gave it a try.
If has a problem with forking processes:
Doing vfork: Resource temporarily unavailable
On 2022-07-17 08:15, Ken Brown wrote:
On 7/17/2022 7:08 AM, Oleksandr Gavenko wrote:
I saw a new version of emacs-w32 28.1-2 (has 28.1-1) and gave it a try.
If has a problem with forking processes:
Doing vfork: Resource temporarily unavailable
Please see the release announcement:
https
On 7/17/2022 7:08 AM, Oleksandr Gavenko wrote:
I saw a new version of emacs-w32 28.1-2 (has 28.1-1) and gave it a try.
If has a problem with forking processes:
Doing vfork: Resource temporarily unavailable
Please see the release announcement:
https://cygwin.com/pipermail/cygwin-announce
I saw a new version of emacs-w32 28.1-2 (has 28.1-1) and gave it a try.
If has a problem with forking processes:
Doing vfork: Resource temporarily unavailable
If I switch to 28.1-1 the problem disappears. When I go back to 28.1-2
it reappears 100%.
I did "rebaseall".
I have Soph
, there was no error report from emacs-w32, it just silently
exited while the compilation was ongoing. I don't know if that was
the desired outcome.
Yes. All I did was to suppress the error report. It turns out that there was
actually a Cygwin bug underlying this, which will be fixed i
> I'm about to announce a new test release that tries to work around the problem
> in a different way. I'd be interested in hearing how that works too.
I updated Emacs and turned off "native-comp-async-query-on-exit".
This time, there was no error report from emacs-w3
> >> I'll add one more thing that I didn't know when I wrote that: You can
> >> customize
> >> the variable native-comp-async-query-on-exit if you want to be warned that
> >> there
> >> are compilations in process when you exit.
> >
> > Sure, that could be the problem. I'll try the workaround.
>
On 10/7/2021 10:16 AM, Jim Reisert AD1C wrote:
Could this be the following problem that I mentioned in the release
announcement?
Compilation is done asynchronously, with a log in a buffer called
*Async-native-compile-log*. If you run emacs-w32 and exit while a
compilation is in progress, you
> Could this be the following problem that I mentioned in the release
> announcement?
>
> > Compilation is done asynchronously, with a log in a buffer called
> > *Async-native-compile-log*. If you run emacs-w32 and exit while a
> > compilation is in progress, you mi
On 10/6/2021 11:38 AM, Ken Brown via Cygwin wrote:
On 10/6/2021 10:22 AM, Jim Reisert AD1C wrote:
The test release of GNU Emacs 28.0.50 crashed on me when using
emacs-w32. I can repeat this every time. I attached the trace and
stackdump.
Windows 11 Pro 64-bit
Take Command 27.01.24 x64
Opened
On 10/6/2021 10:22 AM, Jim Reisert AD1C wrote:
The test release of GNU Emacs 28.0.50 crashed on me when using
emacs-w32. I can repeat this every time. I attached the trace and
stackdump.
Windows 11 Pro 64-bit
Take Command 27.01.24 x64
Opened a text file using emacs-w32
Ctrl-X Ctrl-C to exit
> The test release of GNU Emacs 28.0.50 crashed on me when using
> emacs-w32. I can repeat this every time. I attached the trace and
> stackdump.
Emacs in an X window with this same file did NOT crash. It seems to
be something particular to emacs-w32 or a non-X environment.
--
Ji
The test release of GNU Emacs 28.0.50 crashed on me when using
emacs-w32. I can repeat this every time. I attached the trace and
stackdump.
Windows 11 Pro 64-bit
Take Command 27.01.24 x64
Opened a text file using emacs-w32
Ctrl-X Ctrl-C to exit Exit Emacs
I did not make any changes to the text
X server and run xterm/bash
> windows and Emacs that way.
On daily basis? Why not mintty and emacs-w32?
Originally (2006-2012) I used native Windows Emacs + cygwin-mount.el. There
were compatibility issues, most struggles came from Emacs dependency on
external utilities to be fully fun
On 11/26/2020 3:38 PM, Oleksandr Gavenko via Cygwin wrote:
I believe that X server under Windows is only to write cool blog posts, that
we are able to run "xterm" ))
Not sure what you mean here. I run Cygwin's X server and run xterm/bash windows and Emacs that way.
I was just indicating tha
On 2020-11-26, Eliot Moss wrote:
> Lacks UI? You can run X windows applications in WSL if you have the Cygwin X
> server running :-) ...
> then you get the X UI. I can certainly run xterm and emacs that way.
>
I don't need 2 Emacs instances around. Cygwin's Emacs W3
On Thu, Nov 26, 2020 at 9:22 PM Oleksandr Gavenko wrote:
> So Emacs tries to make some "smart" locking on dumb FS... Need to
> waste another few hours to make Emacs work.
>
Found the problem: Emacs fails on its "unlock-buffer" call from
emacs/src/filelock.c.
Feature described here:
https://www.g
debian /wsl/debian ntfs binary,noacl,posix=0 0 0
//wsl$/ubuntu /wsl/ubuntu ntfs binary,noacl,posix=0 0 0
//wsl$/alpine /wsl/alpine ntfs binary,noacl,posix=0 0 0
$ mkdir -p /wsl/{ubuntu,debian,alpine}
$ mount /wsl/debian
$ mount /wsl/ubuntu
$ mount /wsl/wsl
And the final step it testi
Oleksandr Gavenko via Cygwin writes:
> ...
> WSL1 files are "hidden" for regular access.
I probably misunderstand, but I can see my WSL/Ubuntu files via this
path from Cygwin:
/c/Users/ht/AppData/Local/Packages/CanonicalGroupLimited.../LocalState/rootfs
ht
--
Henry S. Thompson, School
On 11/26/2020 10:18 AM, Oleksandr Gavenko via Cygwin wrote:
> Still WSL 1 lacks UI and integrates less smoothly into my workflow
> to replace Cygwin's amazing Emacs W32.
Lacks UI? You can run X windows applications in WSL if you have the Cygwin X server running :-) ...
then you g
I'm using Cygwin for two reasons: mintty + Emacs w32.
Nowadays WSL 1 has become important (vendors provide ready to work
.deb packages,
I use: Ansible + Google Cloud SDK, if name any).
Still WSL 1 lacks UI and integrates less smoothly into my workflow
to replace Cygwin's amazing
do will launch adbobe pdf in a containter by file
> association rule.
>
> All I need to do is figure out how to get msg2pdf to launch a pdf in
> emacs-w32 with mu4e!
>
> Please assist if you have any cool tips.
>
> thx. -
> Jim McNamara
--
Problem reports: http://cyg
On 11/5/2017 11:38 AM, U-BLASTER-6000\mtdew wrote:
I used to invoke emacs from minty. Now I added emacs-w32 package. Is
there a way I can add a symlink so the non minty version can find my
paths in my emacs config file that are posix like?
Sorry, but I can't understand what you're a
Hi-
I used to invoke emacs from minty. Now I added emacs-w32 package. Is
there a way I can add a symlink so the non minty version can find my
paths in my emacs config file that are posix like?
The reason I am trying is as many know pdf needs javascript turned off
for security.
Then if I want
>From some time I can't run emacs-w32 / emacsclient-w32 via run.exe from
cmd.exe or mintty.exe.
Actually at the end I use chain of call:
``e.bat`` with: run.exe --quote emacsclient-w32 -a e
``e`` with: cygstart --action=runas run emacs-w32
and then:
run --quote emacscl
On 8/22/2016 3:17 AM, Peter Hull wrote:
On 21/08/16 23:03, Ken Brown wrote:
OK, let's wait to hear from Volker (or maybe Yaakov has some insight?).
BTW, I've looked at the sources for gd-2.2.3-1, and the string
"WebPDecode" appears only once, in a call to WebPDecodeARGB. So I
don't understand
On 21/08/16 23:03, Ken Brown wrote:
OK, let's wait to hear from Volker (or maybe Yaakov has some insight?).
BTW, I've looked at the sources for gd-2.2.3-1, and the string
"WebPDecode" appears only once, in a call to WebPDecodeARGB. So I
don't understand why there wasn't an ABI bump between ve
On Sun, 2016-08-21 at 18:03 -0400, Ken Brown wrote:
> On 8/21/2016 11:24 AM, Marco Atzeri wrote:
> > the 32bit depends on both
> >
> > /usr/bin/cyggd-3.dll => libgd3-2.1.1-2
> > /usr/bin/cygwebp-5.dll => libwebp5-0.4.4-1
> >
> > the 64 bit is missing the first.
> > So in theory I should rebu
On 8/21/2016 11:24 AM, Marco Atzeri wrote:
On 20/08/2016 18:54, Ken Brown wrote:
On 8/20/2016 9:41 AM, Marco Atzeri wrote:
On 20/08/2016 04:52, Ken Brown wrote:
On 8/19/2016 4:03 PM, Ken Brown wrote:
On 8/19/2016 11:22 AM, Ken Brown wrote:
On 8/19/2016 9:55 AM, Ken Brown wrote:
On 8/19/2016
On 20/08/2016 18:54, Ken Brown wrote:
On 8/20/2016 9:41 AM, Marco Atzeri wrote:
On 20/08/2016 04:52, Ken Brown wrote:
On 8/19/2016 4:03 PM, Ken Brown wrote:
On 8/19/2016 11:22 AM, Ken Brown wrote:
On 8/19/2016 9:55 AM, Ken Brown wrote:
On 8/19/2016 6:27 AM, Peter Hull wrote:
Hi all,
I
On 8/20/2016 9:41 AM, Marco Atzeri wrote:
On 20/08/2016 04:52, Ken Brown wrote:
On 8/19/2016 4:03 PM, Ken Brown wrote:
On 8/19/2016 11:22 AM, Ken Brown wrote:
On 8/19/2016 9:55 AM, Ken Brown wrote:
On 8/19/2016 6:27 AM, Peter Hull wrote:
Hi all,
The problem turns out to be related to the
On 20/08/2016 04:52, Ken Brown wrote:
On 8/19/2016 4:03 PM, Ken Brown wrote:
On 8/19/2016 11:22 AM, Ken Brown wrote:
On 8/19/2016 9:55 AM, Ken Brown wrote:
On 8/19/2016 6:27 AM, Peter Hull wrote:
Hi all,
The problem turns out to be related to the recent update of libgd3.
Reverting to the p
g happened. 'emacs -Q' and
'emacs --version' do the same, nothing is printed.
My alternatives are set such that emacs points to emacs-w32. I also
have
emacs-nox and that works fine.
If I run 'strace emacs-w32' I get an error dialog:
"The procedure entry point WebPDe
g happened. 'emacs -Q' and
'emacs --version' do the same, nothing is printed.
My alternatives are set such that emacs points to emacs-w32. I also
have
emacs-nox and that works fine.
If I run 'strace emacs-w32' I get an error dialog:
"The procedure entry point WebPDe
7;emacs --version' do the same, nothing is printed.
My alternatives are set such that emacs points to emacs-w32. I also have
emacs-nox and that works fine.
If I run 'strace emacs-w32' I get an error dialog:
"The procedure entry point WebPDecode could not be located in the
dynam
g is printed.
My alternatives are set such that emacs points to emacs-w32. I also have
emacs-nox and that works fine.
If I run 'strace emacs-w32' I get an error dialog:
"The procedure entry point WebPDecode could not be located in the
dynamic link library C:\cygwin\bin\cygMagic
uch that emacs points to emacs-w32. I also have
emacs-nox and that works fine.
If I run 'strace emacs-w32' I get an error dialog:
"The procedure entry point WebPDecode could not be located in the
dynamic link library C:\cygwin\bin\cygMagickCore-6.Q16-2.dll."
Is your i
Hi all,
When I type 'emacs' at the bash prompt, emacs does not start and the
prompt re-appears very quickly as if nothing happened. 'emacs -Q' and
'emacs --version' do the same, nothing is printed.
My alternatives are set such that emacs points to emacs-w32. I
On 2016-05-29, Ken Brown wrote:
> You can avoid the console window by using Cygwin's run.exe. See the shortcut
> for the X server for an example of this. (You do get a brief console window,
> but it immediately disappears.)
Thanks, that helped.
I tested with "Win+R run e
On 5/29/2016 8:43 AM, Oleksandr Gavenko wrote:
On 2016-05-29, Ken Brown wrote:
On 5/28/2016 5:08 PM, Oleksandr Gavenko wrote:
emacs-w32 starts console window and that useless window disturbs during task
switching (by Alt+TAB) and take space on TaskBar.
Is it possible to hide emacs-w32
On 2016-05-29, Ken Brown wrote:
> On 5/28/2016 5:08 PM, Oleksandr Gavenko wrote:
>> emacs-w32 starts console window and that useless window disturbs during task
>> switching (by Alt+TAB) and take space on TaskBar.
>>
>> Is it possible to hide emacs-w32 console window?
&
On 5/28/2016 5:08 PM, Oleksandr Gavenko wrote:
emacs-w32 starts console window and that useless window disturbs during task
switching (by Alt+TAB) and take space on TaskBar.
Is it possible to hide emacs-w32 console window?
Sorry, I don't know what console window you're talking about
emacs-w32 starts console window and that useless window disturbs during task
switching (by Alt+TAB) and take space on TaskBar.
Is it possible to hide emacs-w32 console window?
== TL;TR ===
I uses native Emacs for long time but now emacs-w32
On May 19 08:21, Ken Brown wrote:
> On 5/19/2015 1:52 AM, Martin Anantharaman wrote:
> >Ken,
> >
> >you were on the right track there: I do not run bash in a windows console,
> >but not in mintty either - I have been using Console2 for many years as
> >common terminal for cmd, msys and cygwin. When
On 5/19/2015 1:52 AM, Martin Anantharaman wrote:
Ken,
you were on the right track there: I do not run bash in a windows console,
but not in mintty either - I have been using Console2 for many years as
common terminal for cmd, msys and cygwin. When I run my test in a mintty
windows everything wor
cons1? Are you running these commands in a
Windows console rather than a Cygwin Terminal (mintty)? If so, please try it in
a Cygwin Terminal.
$ emacsclient .shrc
Waiting for Emacs...
(emacsclient returns immediately, task-manager shows there is no more
emacs-w32 process and there is a new s
s in a
Windows console rather than a Cygwin Terminal (mintty)? If so, please try it in
a Cygwin Terminal.
$ emacsclient .shrc
Waiting for Emacs...
(emacsclient returns immediately, task-manager shows there is no more
emacs-w32 process and there is a new stackdump in the working directory)
d not open file: /dev/cons1
$ emacsclient .shrc
Waiting for Emacs...
(emacsclient returns immediately, task-manager shows there is no more
emacs-w32 process and there is a new stackdump in the working directory)
$ cat emacs-w32.exe.stackdump
Stack trace:
Frame Function Args
017075E4
On 5/17/2015 3:44 AM, Martin Anantharaman wrote:
Ken,
thanks for your quick reply. Regarding the problem with emacs --daemon I
should have given the following background:
1) The commands in my listing (it was actually an attached text-file - which
automagically got inlined into the posting) need
Ken,
thanks for your quick reply. Regarding the problem with emacs --daemon I
should have given the following background:
1) The commands in my listing (it was actually an attached text-file - which
automagically got inlined into the posting) need to be executed in that
sequence, i.e. emacs --daem
On 5/15/2015 7:22 AM, Martin Anantharaman wrote:
- Crash in server-mode: One of the advantages of Cygwin emacs-w32 is that it
supports the server-mode via invocation with --daemon (also coming soon to
official Emacs!). But using emacsclient wihtout any options first gives an
error and then
After being a long-time user of the official (MinGW-based) Emacs for
Windows, I am making the transition to Cygwin's emacs-w32, mainly to profit
from the large base of supplementary packages in Cygwin and the automated
update via setup. The transition has not been completely smooth, though
On 7/9/2014 8:22 AM, Corinna Vinschen wrote:
On Jul 9 12:15, Corinna Vinschen wrote:
On Jul 8 09:55, Ken Brown wrote:
On 7/7/2014 3:12 PM, Zdzislaw Meglicki wrote:
Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 4532.0xa100]
0x7ff974f39e3b in KERNELBASE!Debug
On Jul 9 12:15, Corinna Vinschen wrote:
> On Jul 8 09:55, Ken Brown wrote:
> > On 7/7/2014 3:12 PM, Zdzislaw Meglicki wrote:
> > >Program received signal SIGTRAP, Trace/breakpoint trap.
> > >[Switching to Thread 4532.0xa100]
> > >0x7ff974f39e3b in KERNELBASE!DebugBreak () from
> > >/cygdrive
On Jul 9 12:27, Corinna Vinschen wrote:
> On Jul 8 12:44, Christopher Faylor wrote:
> > On Tue, Jul 08, 2014 at 11:36:07AM -0500, Yaakov Selkowitz wrote:
> > >On 2014-07-08 10:02, Christopher Faylor wrote:
> > >> On Tue, Jul 08, 2014 at 09:55:55AM -0400, Ken Brown wrote:
> > >>> Grasping at straw
On Jul 8 12:44, Christopher Faylor wrote:
> On Tue, Jul 08, 2014 at 11:36:07AM -0500, Yaakov Selkowitz wrote:
> >On 2014-07-08 10:02, Christopher Faylor wrote:
> >> On Tue, Jul 08, 2014 at 09:55:55AM -0400, Ken Brown wrote:
> >>> Grasping at straws, as usual, I wonder if these mysterious crashes c
On Jul 8 09:55, Ken Brown wrote:
> On 7/7/2014 3:12 PM, Zdzislaw Meglicki wrote:
> >Program received signal SIGTRAP, Trace/breakpoint trap.
> >[Switching to Thread 4532.0xa100]
> >0x7ff974f39e3b in KERNELBASE!DebugBreak () from
> >/cygdrive/c/WINDOWS/system32/KERNELBASE.dll
> >(gdb) bt
> >#0
On Tue, Jul 08, 2014 at 11:36:07AM -0500, Yaakov Selkowitz wrote:
>On 2014-07-08 10:02, Christopher Faylor wrote:
>> On Tue, Jul 08, 2014 at 09:55:55AM -0400, Ken Brown wrote:
>>> Grasping at straws, as usual, I wonder if these mysterious crashes could
>>> be related to a bug that Corinna just fixe
On 2014-07-08 10:02, Christopher Faylor wrote:
On Tue, Jul 08, 2014 at 09:55:55AM -0400, Ken Brown wrote:
Grasping at straws, as usual, I wonder if these mysterious crashes could
be related to a bug that Corinna just fixed:
https://cygwin.com/ml/cygwin-cvs/2014-q3/msg4.html
Corinna, is
el24.3.91-1OK
>> emacs-w32 24.3.91-1OK
>> emacs-X11 24.3.91-1OK
>>
>> Cygwin is
>> Cygwin DLL version info:
>> DLL version: 1.7.30
>> DLL epoch: 19
>> DLL old termios: 5
On 7/7/2014 3:12 PM, Zdzislaw Meglicki wrote:
The current version of Emacs that I have is
emacs 24.3.91-1OK
emacs debuginfo 24.3.91-1OK
emacs-el24.3.91-1OK
emacs-w32 24.3.91-1OK
emacs-X11
The current version of Emacs that I have is
emacs 24.3.91-1OK
emacs debuginfo 24.3.91-1OK
emacs-el24.3.91-1 OK
emacs-w32 24.3.91-1OK
emacs-X11 24.3.91-1OK
Cygwin is
On 06/17/2014 03:22 PM, Zdzislaw Meglicki wrote:
When I go to snapshots on the Cygwin site, there are
only Cygwin dlls there. Where is the latest Emacs
stuff? And which version of Emacs should go with
which Cygwin dll?
Snapshots are of the Cygwin DLL/package. If you're looking for Emacs, you
g
When I go to snapshots on the Cygwin site, there are
only Cygwin dlls there. Where is the latest Emacs
stuff? And which version of Emacs should go with
which Cygwin dll?
Gustav Meglicki
Indiana University
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygw
24.3-7 OK
>> emacs-w32 24.3-7 OK
>> emacs-X11 24.3-7 OK
> You no longer have the test release of emacs. Every time you run setup,
>
On 6/17/2014 10:47 AM, Zdzislaw Meglicki wrote:
emacs 24.3-7 OK
emacs-debuginfo 24.3-7 OK
emacs-el 24.3-7 OK
emacs-w32
Yes, on running cygcheck -cv gdb I get the same output
as you do: the info documentation is missing. Why is it
missing? Do I need to request it explicitly, or is it
missing from Cygwin distribution?
Gustav Meglicki
Indiana University
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On 17/06/2014 16:47, Zdzislaw Meglicki wrote:
gdb 7.6.50-4
Incomplete
... Is gdb meant to be "Incomplete?" I just ran vanilla
installation, requesting "all."
may be it is just a setup glitch.
Just ask for verbose output
$ cygc
OK
emacs-debuginfo 24.3-7 OK
emacs-el 24.3-7 OK
emacs-w32 24.3-7 OK
emacs-X11
OK, the latest crash, after the latest upgrades,
about which in the follow up posting. I was running
emacs-w32 under gdb. Emacs crashed on segmentation
fault and the backtrace points to... (Emacs) alloc.
Here it is:
Program received signal SIGSEGV, Segmentation fault.
0x7ff9778dec8b in
On Thu, Jun 5, 2014 at 9:51 PM, Christopher Faylor wrote:
> On Thu, Jun 05, 2014 at 03:05:43PM -0400, Ken Brown wrote:
>>On 6/3/2014 6:00 PM, Zdzislaw Meglicki wrote:
>>> And... another crash. I didn't run it under gdb this
>>> time and it didn't dump anything either, but I got
>>> interesting new
On 6/5/2014 3:51 PM, Christopher Faylor wrote:
On Thu, Jun 05, 2014 at 03:05:43PM -0400, Ken Brown wrote:
On 6/3/2014 6:00 PM, Zdzislaw Meglicki wrote:
And... another crash. I didn't run it under gdb this
time and it didn't dump anything either, but I got
interesting new message I didn't see be
On Thu, Jun 05, 2014 at 03:05:43PM -0400, Ken Brown wrote:
>On 6/3/2014 6:00 PM, Zdzislaw Meglicki wrote:
>> And... another crash. I didn't run it under gdb this
>> time and it didn't dump anything either, but I got
>> interesting new message I didn't see before:
>>
>> *** fatal error - WFSO failed
On 6/3/2014 6:00 PM, Zdzislaw Meglicki wrote:
And... another crash. I didn't run it under gdb this
time and it didn't dump anything either, but I got
interesting new message I didn't see before:
*** fatal error - WFSO failed waiting for timer thread, Win32 error 0
This message comes from the f
This is just to confirm: I had a yet another crash,
was running my emacs session under gdb and captured
the event. The trace is the same as before, that is,
there is a problem in deselect_palette that causes
segmentation fault.
Yes, I will report the bug to Emacs maintainers.
Zdzislaw (Gustav) Me
On 6/3/2014 4:01 PM, Zdzislaw Meglicki wrote:
And another crash... captured under gdb again.
Segmentation fault again, but this time:
Program received signal SIGSEGV, Segmentation fault.
0x000100631d84 in deselect_palette (f=0x0, hdc=0x0) at
/usr/src/debug/emacs-24.3.90-1/src/w32xfns.c:123
And... another crash. I didn't run it under gdb this
time and it didn't dump anything either, but I got
interesting new message I didn't see before:
*** fatal error - WFSO failed waiting for timer thread, Win32 error 0
Interesting? Perhaps all these crashes have something to
do with the timer?
Z
:123
123 if (f->output_data.w32->old_palette)
And, unlike the last one that crashed somewhere deep down under Cygwin in
O/S calls, this one never touches the Cygwin DLL. This suggests to me
that this particular problem is shared with any non-Cygwin version of
Emacs-w32. You may w
And another crash... captured under gdb again.
Segmentation fault again, but this time:
Program received signal SIGSEGV, Segmentation fault.
0x000100631d84 in deselect_palette (f=0x0, hdc=0x0) at
/usr/src/debug/emacs-24.3.90-1/src/w32xfns.c:123
123 if (f->output_data.w32->old_palette)
This time we've been running it under gdb and
I managed to capture the crash. It aborted
upon having received SIGABRT, and printed the
following:
Program received signal SIGABRT, Aborted.
0x00010064ed67 in xg_select (fds_lim=4428800, rfds= 0x1800c46cd ,
wfds=0x4392e0, efds=0x439a90, timeout=
On 5/21/2014 4:14 PM, Zdzislaw Meglicki wrote:
It just crashed on me again, after a couple of days
of no crashes at all. The versions of everything
are unchanged since my last message. But this
time, and this is new, I have not seen it before,
it did not give me the gdb option. Instead it just
cr
It just crashed on me again, after a couple of days
of no crashes at all. The versions of everything
are unchanged since my last message. But this
time, and this is new, I have not seen it before,
it did not give me the gdb option. Instead it just
crashed and said: "Segmentation fault (core dumped
On 5/19/2014 10:42 AM, Ken Brown wrote:
On 5/19/2014 9:20 AM, Zdzislaw Meglicki wrote:
(gdb) backtrace
#0 0x7ff9550c9e3b in KERNELBASE!DebugBreak ()
from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#1 0x00010061a344 in emacs_abort ()
at /usr/src/debug/emacs-24.3.90-1/src/w32fns.c:8460
On 5/19/2014 9:20 AM, Zdzislaw Meglicki wrote:
I got it this time. It crashed on me just a few seconds after I started it,
while reading mail with rmail. This time I had the right debug info
installed for this version of emacs and here is the backtrace:
==
ttext 0.18.1.1-3 OK
emacs-mercurial 2.7.1-1 OK
emacs-ocaml 4.01.0-2 OK
emacs-w32 24.3.90-1OK
emac
On 5/14/2014 5:12 PM, Zdzislaw Meglicki wrote:
OK, I've manage to catch it this time. But it looks like
it didn't get very far, because the info in emacs-w32.exe.dbg
appears to be wrong.
[...]
Reading symbols from /usr/bin/emacs-w32.exe...
warning: the debug information found in "
OK, I've manage to catch it this time. But it looks like
it didn't get very far, because the info in emacs-w32.exe.dbg
appears to be wrong. Here's what happens:
515 $ ps -ef
UID PIDPPID TTYSTIME COMMAND
gustav 19900 1 ?07:51:01 /usr/bin/ssh-agent
On 5/13/2014 5:25 PM, Zdzislaw Meglicki wrote:
Ken Brown writeth:
Please describe the crash in more detail.
What were you doing when it happened? Did
the window just disappear, or did you get
a dialogue box asking if you want to attach
a debugger? Did you get any messages in the
terminal that
in, hopefully letting me attach gdb, I'll
post a backtrace and the stackdump file, if you'd
like to have a look at it.
Since emacs-w32 is so much better now, it may very
well take days before the next such event!
(greetings to-all)
Gustav Meglicki,
Indiana University
--
Problem repor
On 5/13/2014 8:16 AM, Zdzislaw Meglicki wrote:
Well, the crashing problem in emacs-w32 is greatly improved,
yet, the program still crashed on me yesterday, after a good
few days of seamless performance. The emacs-version function
returns:
(emacs-version)
"GNU Emacs 24.3.90.1 (x86_64-un
Well, the crashing problem in emacs-w32 is greatly improved,
yet, the program still crashed on me yesterday, after a good
few days of seamless performance. The emacs-version function
returns:
(emacs-version)
"GNU Emacs 24.3.90.1 (x86_64-unknown-cygwin)
of 2014-05-03 on Fiona"
Other
on a new Win7/64 laptop. Every day or so,
I
get a "fatal error" dialog from emacs-w32. It asks me if I want to
debug
it, but I'm not sure what info I could pull from gdb that would be
useful.
Is this a known problem?
Is there any useful information I could provide?
I ins
Ken Brown writes:
> I agree. I'll do that soon.
Thanks Ken. Due to several updates that required reboots I haven't
really been able to run an Emacs instance for as long as I would have
liked, but so far I haven't seen any error or crash.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron m
gt;> Sent: Sunday, April 13, 2014 10:53 AM
> >>>
> >>> I recently installed 1.7.29 on a new Win7/64 laptop. Every day or so,
> I
> >>> get a "fatal error" dialog from emacs-w32. It asks me if I want to
> >> debug
> >>>
error" dialog from emacs-w32. It asks me if I want to
debug
it, but I'm not sure what info I could pull from gdb that would be
useful.
Is this a known problem?
Is there any useful information I could provide?
I installed the test 24.3.90.1 version, and it hasn't crashed once (yet)
so, I
> > get a "fatal error" dialog from emacs-w32. It asks me if I want to
> debug
> > it, but I'm not sure what info I could pull from gdb that would be
> useful.
> >
> > Is this a known problem?
> >
> > Is there any useful information I cou
> -Original Message-
> Of KARR, DAVID
> Sent: Sunday, April 13, 2014 10:53 AM
> Subject: Fatal error from Cygwin emacs-w32 every day or so
>
> I recently installed 1.7.29 on a new Win7/64 laptop. Every day or so, I
> get a "fatal error" dialog from emac
Achim Gratz writes:
> it appears to be one of the timer-triggered crashes
> (these sometimes only produce a lisp error and sometimes crash Emacs and
> I don't think these have anything to do with gnutls).
I've just had one of these timer-triggered elisp errors in the 32bit
v
On 5/2/2014 6:50 AM, Achim Gratz wrote:
Achim Gratz writes:
Sorry for the long delay. I've now ran the two Emacs versions side by
side for two days. The original has crashed twice during that time and
the patched version is still running… so I'd call that a fix. Thanks!
Just as I had sent t
Achim Gratz writes:
> Sorry for the long delay. I've now ran the two Emacs versions side by
> side for two days. The original has crashed twice during that time and
> the patched version is still running… so I'd call that a fix. Thanks!
Just as I had sent this mail, the new Emacs also crashed.
1 - 100 of 184 matches
Mail list logo
