[MPlayer-users] Segfault in vobsub_seek when vobsub_id = 0

Martins Krikis mkrikis at yahoo.com
Thu Jan 1 09:14:53 CET 2004


Hello,

I just found a segfault in the vobsub_seek function.
This is happening with dev-CVS-040101-00:44-3.3.2
(and 1.0pre3-3.3.2). I cannot promise that the
subtitle file is well conforming---I'm completely
clueless about such things. It seems to contain
4 different subtitle id-s: 1 and 2 for "no",
3 and 4 for "en". When I use 'j' to cycle through
these subtitle id-s, the id can also get set to
-1 ("none") and to 0 ("unknown"). It is the "unknown"
setting which causes trouble if I do a seek, the
other id settings are OK. O or "unknown" is also
the starting setting unless I specify -slang.
(And, specifying -sid doesn't choose any subtitle
id/language, only -slang works, BTW.)

Here is what it looks like in the gdb:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 17932)]
0x080f0a49 in vobsub_seek (vobhandle=0x0,
pts=12.0400009) at vobsub.c:1279
1279        while ((queue->packets +
queue->current_index)->pts100 < seek_pts100)
(gdb) where
#0  0x080f0a49 in vobsub_seek (vobhandle=0x0,
pts=12.0400009) at vobsub.c:1279
#1  0x080e086b in main (argc=2, argv=0xbffff464) at
mplayer.c:3380
(gdb) p *queue
$1 = {id = 0x0, packets = 0x0, packets_reserve = 0,
packets_size = 0, 
  current_index = 0}
(gdb) p queue
$2 = (packet_queue_t *) 0x84eb9f0
(gdb) p vobsub_id
$3 = 0

Here is what I think about the cause:
0 apparently was not a valid id in the subtitle 
file (not sure whether it should have been) and 
vobsub_ensure_spu_stream likely never got called 
with index = 0 (I checked for this under gdb until
I got tired of seeing all the other indices again
and again, not 0). Thus, my conjecture is that 
there is no valid "spu_stream" corresponding to
subtitle id 0 and therefore the vobsub_seek segfaults.

I'm not sure what the right fix is. Keeping track
of the lowest subtitle id and checking against
that instead of 0? Keeping a list of all subtitle
id-s in use (assuming that there can be holes)?
Not allowing it to cycle through 0 and not
defaulting to it?

I can provide the disassembly and registers
and all the recommended bug reporting info,
but I feel that what I said already describes
it reasonably well. Please let me know if this
is not so. 

Thanks very much for your efforts.

  Martins Krikis

P.S.

The following quick hack to vobsub.c
solved the problem for me but I don't think
that it is the right fix.


% diff -Naur vobsub.c.~1.37.~ vobsub.c
--- vobsub.c.~1.37.~    2004-01-01 02:49:44.000000000
-0500
+++ vobsub.c    2004-01-01 02:50:34.000000000 -0500
@@ -1273,7 +1273,7 @@
   packet_queue_t * queue;
   int seek_pts100 = (int)pts * 90000;
 
-  if (vob->spu_streams && 0 <= vobsub_id &&
(unsigned) vobsub_id < vob->spu_streams_size) {
+  if (vob->spu_streams && 0 < vobsub_id && (unsigned)
vobsub_id < vob->spu_streams_size) {
     queue = vob->spu_streams + vobsub_id;
     queue->current_index = 0;
     while ((queue->packets +
queue->current_index)->pts100 < seek_pts100)



__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003




More information about the MPlayer-users mailing list