[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#569591: marked as done (Filename error handling)



Your message dated Thu, 8 Sep 2022 15:44:29 +0200
with message-id <6584e1a8-3f5d-8520-bff2-1c9339bd73d8@linux-dev.org>
and subject line Closing already long fixed bugs
has caused the Debian Bug report #569591,
regarding Filename error handling
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
569591: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569591
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: xine-ui
Version: 0.99.5+cvs2007

Hi!

I was looking at bug #510606 and started trying to reproduce it.
However, I can't see exactly the behaviour the original reporter described, 
but I see that xine gets a bit picky with long filenames, empty files and 
invalid paths, so I decided to write that up separately.



> # test 1
> $ touch 1234567890
> $ xine 1234567890
> 
> This is xine (X11 gui) - a free video player v0.99.6cvs.
> (c) 2000-2007 The xine Team.
> system call fstat: Bad file descriptor
> system call fstat: Bad file descriptor
> object not accessible
> call failed

The weird things there are the calls to fstat with bad file descriptors. While 
this seems to be caught, it is an indicator of something going very wrong. 
Note that the filename is really only ten characters long, it rather seems to 
be related to the fact that the file is empty. When I ran xine on a logfile 
(just for testing), it didn't produce those two lines.

Anyway, what xine does here is to produce two popups. The first one is

>  "*sight*, unknown error. (File is empty: 1234567890)

Well, obviously the error is known, so that doesn't make sense. (Also it 
probably should be "*sigh*" not "*sight*".) The second popup is

> - xine engine error -
> Input plugin failed to open mrl '1234567890'

This error seems a) wrong, since it did manage to open the file and b) 
superfluous since the first popup already explains all. Another weird things 
is that these two popups don't come in a fixed order! Most of the time the 
first one is in front of the second one, but not always!



> # test 2
> $ touch 1234567890
> $ xine `pwd`1234567890
> 
> This is xine (X11 gui) - a free video player v0.99.6cvs.
> (c) 2000-2007 The xine Team.
> object not accessible
> call failed

Note here that the resulting argument does not actually resolve to a file, 
since 'pwd' doesn't have a trailing slash in its output. Again, I get two 
error popups, while one is enough.



> # test 3
> # these are actually 200 characters below!
> $ touch 1234567890...1234567890
> $ xine `pwd`1234567890...1234567890
> This is xine (X11 gui) - a free video player v0.99.6cvs.
> (c) 2000-2007 The xine Team.
> xiTK received SIGSEGV signal, RIP.
> Aborted
> xdg-screensaver: Window 71303875 does not exist

Here, xine actually aborted with a segmentation violation. For a split second, 
it displayed the message

> - xine engine error -
> Input plugin failed to open mrl '/home/uli/tmp12345678901234567

Note here that the text really ends with a cut off path. Neither the full path 
is given nor even the closing single quote! Running the same in GDB produces 
the following output:

> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x4f0f1480 (LWP 4765)]
> _wordcopy_bwd_dest_aligned (dstp=1318006776,
>                             srcp=1318006768,
>                             len=1071651524) at wordcopy.c:391
> object not accessible
> 391     wordcopy.c: No such file or directory.
>         in wordcopy.c
> (gdb) bt
> #0  _wordcopy_bwd_dest_aligned (dstp=1318006776,
>                                 srcp=1318006768,
>                                 len=1071651524) at wordcopy.c:391
> #1  0x0faa89dc in *__GI_memmove (dest=0x4f0ec4f2,
>                                  src=<value optimized out>,
>                                  len=4294967282) at memmove.c:99
> #2  0xe010069b in ?? ()
> Cannot access memory at address 0xf44f0ee8

Things to note here are that xine is trying to copy one billion (hex 
0x3fe01ac4) words, which is more that a process in a 32-bit environment has as 
virtual address space, I think.
Further up the stack, it is doing a __GI_memmove() which has as an actual size 
the value 0xfffffff2. How that value converts to a length of 0x3fe01ac4 in the 
call to _wordcopy_bwd_dest_aligned() is beyond me, and possibly worth a bug 
for some other code.

Further testing with GDB turned up a few more things:
 1. (gdb) run /home/uli/tmp1234567890
This creates an error message (no surprise here) but otherwise works as 
expected.
 2. (gdb) run /home/uli/tmp12345678901234567890
This creates the same error messages, but on shutdown, xine receives a SIGSEGV 
in _int_free(). In the call stack is XCloseDisplay() though, so that might be 
a bug in Xlib.
 3. (gdb) run /home/uli/tmp123456789012345678901234567890
Same as case 2.
 4. (gdb) run /home/uli/tmp1234567890123456789012345678901234567890
At this size, it suddenly runs normally! I tried multiple times, I didn't see 
the same effect as with cases 2 and 3.
 5. (gdb) run /home/uli/tmp12345678901234567890123456789012345678901234567890
Here we get the effects described above, with the SIGSEGV in the call to 
_wordcopy_bwd_dest_aligned().



The effects are all easy to reproduce. I'm going to compile a version locally 
with debug symbols and see if I can create more info or even a patch tomorrow.

Cheers and good evening!

Uli



--- End Message ---
--- Begin Message ---
Please feel free to reopen if I am wrong, but retest it with 0.99.13

--- End Message ---

Reply to: