Re: xawtv segfaults with 2.2.3-ac1 (not 2.2.3)

Nathan Hand (nathanh@wookie.chirp.com.au)
Fri, 12 Mar 1999 20:19:03 +1100 (EST)


On Thu, 11 Mar 1999, Dag Wieers wrote:

> Mar 11 02:33:40 lisse wmaker[23293]: This is xawtv-2.37, running on Linux/i686 (2.2.3-ac1)
> Mar 11 02:33:40 lisse wmaker[23293]: x11: 1280x1024, 16 bit/pixel, 0 byte/scanline
> Mar 11 02:33:41 lisse wmaker[23293]: v4l: device is BT878(Hauppauge new)
> Mar 11 02:33:41 lisse wmaker[23293]: mmap: Invalid argument
> Mar 11 02:33:41 lisse wmaker[23293]: v4l: 1280x1024, 16 bit/pixel, 2560 byte/scanline
>
> i never got the mmap: invalid argument part before either.
>
> (and since the 2.2.3-ac1 patch doesn't touch any bttv-code, it must be the
> framebuffers ?)

Running gdb with a debug linked version of xawtv produces the following
backtrace after the segfault.

#0 0x401fa95e in memset ()
#1 0x805663b in grab_queue (gb=0xbffff8f8) at grab-v4l.c:525
#2 0x80567dd in grab_probe (format=3) at grab-v4l.c:578
#3 0x80568e2 in grab_setparams (format=3, width=0x8063d18,
height=0x8063d1c) at grab-v4l.c:611
#4 0x8055533 in grabber_setparams (format=3, width=0x8063a8c,
height=0x8063a90, lut_valid=1) at grab.c:191
#5 0x804bf99 in grabdisplay_setsize (width=384, height=288) at main.c:426
#6 0x804c0b6 in resize_event (widget=0x80714f0, client_data=0x0,
event=0xbffffa5c, d=0xbffff9af "\001") at main.c:461
#7 0x400b9c69 in ()
#8 0x400ba5e6 in ()
#9 0x400ba985 in ()
#10 0x400bad6d in ()
#11 0x805065b in main (argc=1, argv=0xbffffb84) at main.c:2437

Looking at the code in question

static int
grab_queue(struct video_mmap *gb)
{
if (debug > 1)
fprintf(stderr,"g%d",gb->frame);
#if 1
/* FIXME */
memset(map + gb_buffers.offsets[gb->frame],0,
gb_buffers.size/gb_buffers.frames);
#endif

Looks like the fault runs deep, and people know about it. Commenting
out the code (#if 0) lets you get the app up, but it segfaults later
in another file, another memset, when trying to change channels.

This worked fine with 2.2.2-ac7, failed with 2.2.3-ac1. So something
in the kernel has changed to cause the fault, but that comment seems
to suggest its not the kernel actually at fault here.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/