headers
Eli Zaretskii | 1 Apr 2008 05:07
Picon

Re: 23.0.60; uid problems on w32

> Date: Mon, 31 Mar 2008 22:42:02 +0200
> From: "Lennart Borgman (gmail)" <lennart.borgman <at> gmail.com>
> CC: jasonr <at> gnu.org, monnier <at> iro.umontreal.ca, emacs-pretest-bug <at> gnu.org
> 
> Eh, sorry. I meant "how can you from the uid choose the SID from all 
> those SIDs mapping to this uid"?

You can't, but that's not needed, since, as I wrote earlier, such
situations happen on Unix as well, and so Posix programs don't expect
unique uid's.

What I meant was that you can correctly map a SID to a user or group
name, even if some users/groups are not from the local machine (e.g.,
because some of the files are remote files given in the
\\server\share\foo UNC format).
Permalink | Reply | 0 comments |
headers
Jan Djärv | 1 Apr 2008 10:38
Picon

Re: 23.0.60; Odd behavior of maximized windows


> Jan Djärv wrote:
>>
>> David Abrahams skrev:
>>> on Sun Mar 30 2008, Jan Djärv <jan.h.d-AT-swipnet.se> wrote:
>>>
>>>> I also run Emerald, Gnome, Compiz and alse see Emerald crashes.  I
>>>> don't have
>>>> maximized Emacs:es.  But I see that sometimes compiz maximizes
>>>> windows by
>>>> itself when the become "too large" (exactly what that means I don't
>>>> know).
>>>>
>>>> Do you have other maximized windows that don't cover the entire
>>>> screen after a
>>>> restart?  
>>> Yes.
>>>
>>>> Window manager decorations is really up to the window manager, Emacs
>>>> doesn't do anything about this by itself.
>>> I figured as much, but it must be doing something differently from,
>>> e.g., Thunderbird, or I wouldn't be seeing this effect.
>>>
>> I will run some tests.  I guess there is some property one should set
>> which Emacs doesn't.  Stay tuned...

I have run several tests and killed Emerald manually, but my Emacs always 
comes back with window decorations.

When Emacs is maximized, the window manager sets _NET_WM_STATE, usually to
(Continue reading)

Permalink | Reply | 0 comments |
headers
William Xu | 1 Apr 2008 10:55
Picon
Gravatar

emacs hangs at occasions using tramp + opensshd(cygwin)

I'm editing some text files on a remote Windows XP machine, using tramp
+ opensshd(on cygwin).  Occasionally, emacs would suddenly hang.  I
have experienced this several times, but still have no clue what might
cause that.  Today luckily I started it in gdb, so I got a backtrace
attached below: 

---------------------------------8<------------------------------------- 
(gdb) bt 10
#0  0x9083072e in select$DARWIN_EXTSN$NOCANCEL ()
#1  0x9087eba1 in select ()
#2  0x0014799b in *_sys_select$UNIX2003 (nfds=26, rfds=0xbfffae98, wfds=0x0,
efds=0x0, timeout=0xbfffaf18) at mac.c:5138
#3  0x0012f03f in wait_reading_process_output (time_limit=1, microsecs=0,
read_kbd=0, do_display=0, wait_for_cell=2
5165833, wait_proc=0x18ad5190, just_wait_proc=0) at process.c:4601
#4  0x001313e4 in Faccept_process_output (process=414011796, seconds=8,
millisec=25165833, just_this_one=25165833) at process.c:3971
#5  0x000f3ecc in Ffuncall (nargs=4, args=0xbfffb050) at eval.c:3003
#6  0x0012618b in Fbyte_code (bytestr=35867795, vector=379803252, maxdepth=4)
at bytecode.c:679
#7  0x000f3791 in funcall_lambda (fun=379803380, nargs=2,
arg_vector=0xbfffb1d4) at eval.c:3180
#8  0x000f3cab in Ffuncall (nargs=3, args=0xbfffb1d0) at eval.c:3050
#9  0x0012618b in Fbyte_code (bytestr=36100227, vector=379807748, maxdepth=8)
at bytecode.c:679

(gdb) bt 3 full
#0  0x9083072e in select$DARWIN_EXTSN$NOCANCEL ()
No symbol table info available.
#1  0x9087eba1 in select ()
(Continue reading)

Permalink | Reply | 0 comments |
headers
William Xu | 1 Apr 2008 10:56
Picon
Gravatar

emacs hangs at occasions using tramp + opensshd(cygwin)

I'm editing some text files on a remote Windows XP machine, using tramp
+ opensshd(on cygwin).  Occasionally, emacs would suddenly hang.  I
have experienced this several times, but still have no clue what might
cause that.  Today luckily I started it in gdb, so I got a backtrace
attached below: 

---------------------------------8<------------------------------------- 
(gdb) bt 10
#0  0x9083072e in select$DARWIN_EXTSN$NOCANCEL ()
#1  0x9087eba1 in select ()
#2  0x0014799b in *_sys_select$UNIX2003 (nfds=26, rfds=0xbfffae98, wfds=0x0,
efds=0x0, timeout=0xbfffaf18) at mac.c:5138
#3  0x0012f03f in wait_reading_process_output (time_limit=1, microsecs=0,
read_kbd=0, do_display=0, wait_for_cell=2
5165833, wait_proc=0x18ad5190, just_wait_proc=0) at process.c:4601
#4  0x001313e4 in Faccept_process_output (process=414011796, seconds=8,
millisec=25165833, just_this_one=25165833) at process.c:3971
#5  0x000f3ecc in Ffuncall (nargs=4, args=0xbfffb050) at eval.c:3003
#6  0x0012618b in Fbyte_code (bytestr=35867795, vector=379803252, maxdepth=4)
at bytecode.c:679
#7  0x000f3791 in funcall_lambda (fun=379803380, nargs=2,
arg_vector=0xbfffb1d4) at eval.c:3180
#8  0x000f3cab in Ffuncall (nargs=3, args=0xbfffb1d0) at eval.c:3050
#9  0x0012618b in Fbyte_code (bytestr=36100227, vector=379807748, maxdepth=8)
at bytecode.c:679

(gdb) bt 3 full
#0  0x9083072e in select$DARWIN_EXTSN$NOCANCEL ()
No symbol table info available.
#1  0x9087eba1 in select ()
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Albinus | 1 Apr 2008 12:20
Picon
Picon
Gravatar

Re: emacs hangs at occasions using tramp + opensshd(cygwin)

William Xu <william.xwl <at> gmail.com> writes:

> I'm editing some text files on a remote Windows XP machine, using tramp
> + opensshd(on cygwin).  Occasionally, emacs would suddenly hang.  I
> have experienced this several times, but still have no clue what might
> cause that.  Today luckily I started it in gdb, so I got a backtrace
> attached below: 
>
> #4  0x001313e4 in Faccept_process_output (process=414011796, seconds=8,
> millisec=25165833, just_this_one=25165833) at process.c:3971

Tramp is waiting for output from the local ssh process. For further
analysis, it might be useful if you set (setq tramp-verbose 10) before
the next test run.

The resulting Tramp debug buffer could give us more information.
Please send it via "M-x tramp-submit-bug".

Best regards, Michael.
Permalink | Reply | 0 comments |
headers
William Xu | 1 Apr 2008 12:32
Picon
Gravatar

Re: emacs hangs at occasions using tramp + opensshd(cygwin)

Michael Albinus <michael.albinus <at> gmx.de> writes:

> The resulting Tramp debug buffer could give us more information.
> Please send it via "M-x tramp-submit-bug".

I'm afraid when emacs hangs, any key inputs are non-responsive.  The
only thing i can do to kill it and restart.  

--

-- 
William

http://williamxu.net9.org
Permalink | Reply | 1 comment |
headers
William Xu | 1 Apr 2008 13:25
Picon
Gravatar

Re: emacs hangs at occasions using tramp + opensshd(cygwin)

Enter your bug report in this message, including as much detail as you
possibly can about the problem, what you did to cause it and what the
local and remote machines are.

If you can give a simple set of instructions to make this bug happen
reliably, please include those.  Thank you for helping kill bugs in
TRAMP.

Another useful thing to do is to put (setq tramp-debug-buffer t) in
the ~/.emacs file and to repeat the bug.  Then, include the contents
of the *tramp/foo* buffer and the *debug tramp/foo* buffer in your bug
report.

--bug report follows this line--

I managed to get all the following through `emacsclient -e'.  One
interesting thing is that when I run tramp-submit-bug from emacsclient,
the emacs server will allow me to write title in the minibuffer, select
the y-or-n-p question, and after that, it refuses any key inputs again...

When emacs hangs: 

,----[ minibuffer ]
| trmap: file attributes with perl: /ssh:/.../
`----

The following is the tramp debug buffer, IIUC? 

,----[ "*tramp/ssh xwl <at> ananas*" ] 
| (nil 1 1003 513 (18418 5134) (18417 61710) (18417 61710) 2806 33216 t (0 . 10609) -1)
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Abrahams | 1 Apr 2008 16:43
Picon
Picon
Favicon
Gravatar

Re: 23.0.60; Odd behavior of maximized windows

Jan Djärv wrote:
> 
>> Jan Djärv wrote:
>>>
>>> David Abrahams skrev:
>>>> on Sun Mar 30 2008, Jan Djärv <jan.h.d-AT-swipnet.se> wrote:
>>>>
>>>>> I also run Emerald, Gnome, Compiz and alse see Emerald crashes.  I
>>>>> don't have
>>>>> maximized Emacs:es.  But I see that sometimes compiz maximizes
>>>>> windows by
>>>>> itself when the become "too large" (exactly what that means I don't
>>>>> know).
>>>>>
>>>>> Do you have other maximized windows that don't cover the entire
>>>>> screen after a
>>>>> restart?  
>>>> Yes.
>>>>
>>>>> Window manager decorations is really up to the window manager, Emacs
>>>>> doesn't do anything about this by itself.
>>>> I figured as much, but it must be doing something differently from,
>>>> e.g., Thunderbird, or I wouldn't be seeing this effect.
>>>>
>>> I will run some tests.  I guess there is some property one should set
>>> which Emacs doesn't.  Stay tuned...
> 
> I have run several tests and killed Emerald manually, but my Emacs
> always comes back with window decorations.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
brep | 1 Apr 2008 17:02
Picon

23.0.60; dired: No data available

Dired complains "No data available":

  /home/brep/temp/ffmpeg:
  /bin/ls: /home/brep/temp/ffmpeg/.: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./ffmpeg.c: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./tests: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./libavcodec: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./output_example.c: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./ffserver.h: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./libavutil: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./.: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./version.sh: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./libavdevice: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./Doxyfile: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./CREDITS: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./Makefile: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./cmdutils.c: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./..: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./cmdutils.h: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./ffserver.c: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./Changelog: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./libavformat: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./common.mak: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./INSTALL: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./MAINTAINERS: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./TAGS: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./COPYING.LGPL: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./doc: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./tools: No data available
  /bin/ls: /home/brep/temp/ffmpeg/./vhook: No data available
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Djärv | 1 Apr 2008 17:35
Picon

Re: 23.0.60; Odd behavior of maximized windows


David Abrahams skrev:
> Jan Djärv wrote:
>>> Jan Djärv wrote:
>>>> David Abrahams skrev:
>>>>> on Sun Mar 30 2008, Jan Djärv <jan.h.d-AT-swipnet.se> wrote:
>>>>>
>>>>>> I also run Emerald, Gnome, Compiz and alse see Emerald crashes.  I
>>>>>> don't have
>>>>>> maximized Emacs:es.  But I see that sometimes compiz maximizes
>>>>>> windows by
>>>>>> itself when the become "too large" (exactly what that means I don't
>>>>>> know).
>>>>>>
>>>>>> Do you have other maximized windows that don't cover the entire
>>>>>> screen after a
>>>>>> restart?  
>>>>> Yes.
>>>>>
>>>>>> Window manager decorations is really up to the window manager, Emacs
>>>>>> doesn't do anything about this by itself.
>>>>> I figured as much, but it must be doing something differently from,
>>>>> e.g., Thunderbird, or I wouldn't be seeing this effect.
>>>>>
>>>> I will run some tests.  I guess there is some property one should set
>>>> which Emacs doesn't.  Stay tuned...
>> I have run several tests and killed Emerald manually, but my Emacs
>> always comes back with window decorations.
>>
>> When Emacs is maximized, the window manager sets _NET_WM_STATE, usually to
(Continue reading)

Permalink | Reply | 0 comments |

Gmane