On Wed, May 14, 2014 at 08:07:26PM -0400, Ken Brown wrote:
>Are we close to a resolution of the problems with default manifests? It
>looks to me like all the pieces are in place, but maybe I've missed
>something:
>
> https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01387.html
> https://sourcewa
> > gcc compiler also crashed, but i did not investigate it. All
> problems
> > got fixed when i downgraded cygwin package to version 1.7.28-2.
>
> Please try a recent snapshot from http://cygwin.com/snapshots/
Tried. /bin/sh runs well, but gcc still randomly crashes.
Kind regards,
Pavel Fedin
Yes, I am running emacs-w32.exe. And yes, it's specific to `emacs --daemon'.
Thanks.
On Wed, May 14, 2014 at 10:58 PM, Ken Brown wrote:
> On 5/14/2014 1:27 AM, Arthur Tu wrote:
>>
>> I installed the latest 24.4 pretest version. I didn't do experiments
>> on v24.3 on cygwin.
>> $ emacs --version
> >> I'm hoping that I've provided enough of a lead for someone of authority
> >> to decide where things are right, and where things are wrong.
> >
> >Yes, I think so!
> >
> >Thanks a lot, Shaddy. That takes us a long way to a solution. I'll look
> >at it from there as soon as I can.
>
> Andrew
Are we close to a resolution of the problems with default manifests? It
looks to me like all the pieces are in place, but maybe I've missed
something:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01387.html
https://sourceware.org/bugzilla/show_bug.cgi?id=16790#c9
https://sourceware.org/
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 "/usr/lib/debug//
On Wed, May 14, 2014 at 02:15:38PM -0400, Andrew Schulman wrote:
>
>
>> The 32-bit defines TERMINFO:
>>
>> config.h:
>>
>> /*
>> * Define TERMINFO if your machine emulates the termcap routines
>> * with the terminfo database.
>> * Thus the .screenrc file is parsed for
>> * the command 'te
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
gustav 38280 17
> The 32-bit defines TERMINFO:
>
> config.h:
>
> /*
> * Define TERMINFO if your machine emulates the termcap routines
> * with the terminfo database.
> * Thus the .screenrc file is parsed for
> * the command 'terminfo' and not 'termcap'.
> */
> #define TERMINFO 1
>
> configure.log:
>
H,
On 2014-05-15 02:46+0100, Andrew Schulman wrote:
The problem only occurs with screen on 64-bit Cygwin. The 32-bit appears
to work correctly. The problem is that when screen is run in mintty, it
seems to exclude the bottom line, reducing the actual size of the
buffer. Further, something goes
On Wed, May 14, 2014 at 04:36:59PM +0100, Henry S. Thompson wrote:
>Christopher Faylor writes:
>> If you have control over the code you could have it print a pid, wait,
>> and then attach to it with gdb. That works.
>
>Understood, will do.
I should have mentioned, as an alternative approach, if y
Corinna Vinschen writes:
> Yes, this might be better discussed in cygwin-apps. I guess the setting
> of MANPATH is mainly historical.
I'd be happy to not set MANPATH in /etc/profile if we no longer need it
for the standard installation.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron mic
Christopher Faylor writes:
> On Wed, May 14, 2014 at 04:10:36PM +0100, Henry S. Thompson wrote:
>>I'm trying to debug a problem with xemacs that involves the child
>>process forked when you execute M-x shell.
>>
>>None of the mechanisms in the gdb documentation for choosing to step
>>into the chil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14.05.2014 19:25, Christopher Faylor wrote:
> On Wed, May 14, 2014 at 04:10:36PM +0100, Henry S. Thompson wrote:
>> I'm trying to debug a problem with xemacs that involves the child
>> process forked when you execute M-x shell.
>>
>> None of the m
On May 14 16:10, Henry S. Thompson wrote:
> I'm trying to debug a problem with xemacs that involves the child
> process forked when you execute M-x shell.
>
> None of the mechanisms in the gdb documentation for choosing to step
> into the child process (instead of the parent) after a fork() seem t
On Wed, May 14, 2014 at 04:10:36PM +0100, Henry S. Thompson wrote:
>I'm trying to debug a problem with xemacs that involves the child
>process forked when you execute M-x shell.
>
>None of the mechanisms in the gdb documentation for choosing to step
>into the child process (instead of the parent) a
I'm trying to debug a problem with xemacs that involves the child
process forked when you execute M-x shell.
None of the mechanisms in the gdb documentation for choosing to step
into the child process (instead of the parent) after a fork() seem to
work for me. That is, in particular, setting foll
tors' should now
> > return "no such user" for you as well.
>
> > I just created new snapshots on http://cygwin.com/snapshots/
> > Please give'em a try.
>
> Done, and now
>
> [x86_64 20140514]> id Administrators
> id: Administrators: n
On 5/14/2014 1:27 AM, Arthur Tu wrote:
I installed the latest 24.4 pretest version. I didn't do experiments
on v24.3 on cygwin.
$ emacs --version
GNU Emacs 24.3.90.1
Problem reproduced by these steps:
1. "emacs -q --daemon"to open a daemon
2. "emacsclient -c" to open a client
3. "Ctrl+
lone vs. domain machines.
> I applied a patch now which checks the incoming names for validity under
> the current naming rules, so, in theory, `id Administrators' should now
> return "no such user" for you as well.
> I just created new snapshots on http://cygwin.com/snapsh
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
On May 13 22:15, Henry S. Thompson wrote:
> Corinna Vinschen writes:
> > On May 13 18:29, Henry S. Thompson wrote:
> >> Glitch (also true for x86 1.7.29-2):
> >> id returns effectively immediately for all users and non-users _except_:
> >>> time id Administrators
> >> uid=544(+Administrat
--- On Tue, 2014/5/13, Corinna Vinschen wrote:
> On May 13 08:54, Tatsuro MATSUOKA wrote:
> > --- On Mon, 2014/5/12, Corinna Vinschen wrote:
> > > First, are you shure this is running under the snapshot? what does
> > > `uname -a' print when called right before the below gdb call?
> >
> > I have
23 matches
Mail list logo
