Re: possible progress on XO-1 camera issues
Hi there,
On Sat, 19 Dec 2009 12:06:41 +, Tomeu Vizoso
wrote:
> On Sat, Dec 19, 2009 at 07:00, John Gilmore wrote:
>>> #10 0xb67fae59 in gst_xvimagesink_xvimage_put (xvimagesink=0x8364160)
>>> at xvimagesink.c:864
>>> src = {x = 134867456, y = 140758336, w = -1259457208, h = 1}
>>> dst = {x = 137730309, y = 3, w = 0, h = 137691184}
>>> result = {x = 0, y = 0, w = 322, h = 241}
>>> draw_border = 322
>>> __PRETTY_FUNCTION__ = "gst_xvimagesink_xvimage_put"
>>>
>>> The src.w value is in the same range as the Xlib function addresses;
>>> -1259457208 is 0x4B11CAB8 and as can be seen from the call frame #9
>>> the XSync function is at 0x4b0eccf7. The other values seem
>>> irrational. This may be evidence that the stack has been corrupted
>>> somewhere else, or the values not initialised.
>>
>> Just to rule out going too far down a blind alley...
>>
>> Try adding a printf of these values to the code there, rather than or
>> in addition to using GDB. GDB may not be 100% reliable when accessing
>> variables from optimized code. (I used to maintain GDB, and I worked
>> very hard to make it never lie to you, but that precept hasn't always
>> been followed in the intervening decade, and optimizations have also
>> gotten a lot more complicated.)
>>
>> Or try compiling that code without -O and see if that changes either
>> its behavior, or what the debugger reports.
>
> At this point is when I would run totem in valgrind, I can help
> interpreting the output if it's not clear.
>
> # yum install valgrind
> $ valgrind totem
I hope it helps,
http://oficina.paraguayeduca.org/~crodas/valgrind-debug.txt
cheers,
>
> Regards,
>
> Tomeu
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
Hello, On Fri, 18 Dec 2009 14:19:58 -0300, crodas wrote: > Hello Tomeu, > > I regenerated the debug files using what you suggested me, it seems to be > more information. > > I've attached to this e-mail. > > Regards, > > PS: If attaches to the mailing list is not allowed, please let me know. It doesn't accept :-) Here is the debug file: http://oficina.paraguayeduca.org/~crodas/X-totem-debug-2.log > > On Fri, 18 Dec 2009 08:55:05 -0200, Tomeu Vizoso > wrote: >> On Thu, Dec 17, 2009 at 18:08, César D. Rodas >> wrote: >>> Hi Peter, >>> >>> On Thu, 2009-12-17 at 16:33 +, Peter Robinson wrote: >>>> >> >> > I'm looking forward to read clues about how to fix it. >>>> >> >> >>>> >> >> It sounds suspiciously like a Xv issue. That could be anything >>>> >> >> from a >>>> >> >> missing kernel module to a X driver bug. Out of interest can you >>>> >> >> play >>>> >> >> video using totem? Possibly record a video using a XO-1 with the >>>> >> >> working 802 build and see if it will play on one with the F11 >>>> >> >> build. >>>> >> >> That would rule out that issue, or possibly we could craft up a >>>> >> >> gstreamer pipeline that takes the output of the camera and >>>> >> >> displays it >>>> >> >> on the screen. Let me know how you go with the totem test and > then >>>> >> >> we'll see where we can take it from there, if that works I can >>>> >> >> work >>>> >> >> out what the pipeline would need to be to test that raw. >>>> >> > >>>> >> > Well, I've tried what you've suggested me, and it has the same >>>> >> > problem. >>>> >> > >>>> >> > $ totem /media/34F7-79FD/11-Music-Painter\ \(medium\).ogg >>>> >> > >>>> >> > Gdk-ERROR **: The program 'totem' received an X Window System >>>> >> > error. >>>> >> > This probably reflects a bug in the program. >>>> >> > The error was 'BadAlloc (insufficient resources for operation)'. >>>> >> > (Details: serial 101 error_code 11 request_code 131 minor_code >>>> >> > 19) >>>> >> > (Note to programmers: normally, X errors are reported >>>> >> > asynchronously; >>>> >> > that is, you will receive the error a while after causing it. >>>> >> > To debug your program, run it with the --sync command line >>>> >> > option to change this behavior. You can then get a meaningful >>>> >> > backtrace from your debugger if you break on the gdk_x_error() >>>> >> > function.) >>>> >> > aborting... >>>> >> > aborted >>>> >> > >>>> >> > >>>> >> > Is this output helping somehow? Is there a way I can help out to >>>> >> > fix it? >>>> >> >>>> >> Yes, it looks like an X bug. I had a similar issue previously with >>>> >> another X driver. To get a proper backtrace using GDB can you do > the >>>> >> following, this will then allow us to file a bug. >>>> >> >>>> >> Run gdb and then from the gdb prompt run the following commands. If >>>> >> gdb isn't installed you'll need to do a 'yum install -y gdb'. > You'll >>>> >> probably need to install quite a few debuginfo packages to ensure > we >>>> >> get a useful backtrace but if you post the backtrace first we can >>>> >> work >>>> >> out what we need. >>>> >> >>>> >> (gdb) exec-file totem --sync >>>> >> (gdb) break gdk_x_error() >>>> >> (gdb) r >>>> >> >>>> >> You'll then get totem come up. Try and play the video as before and >>>> >> you'll have it crash. The run the following with gdb >>>> >> >>>> >> (gdb) thread apply all bt >>>> >> >>>> >> and paste the complete output into a file and put it somewhere I > can >>>> >> see it (it might
Re: possible progress on XO-1 camera issues
Hello Tomeu, I regenerated the debug files using what you suggested me, it seems to be more information. I've attached to this e-mail. Regards, PS: If attaches to the mailing list is not allowed, please let me know. On Fri, 18 Dec 2009 08:55:05 -0200, Tomeu Vizoso wrote: > On Thu, Dec 17, 2009 at 18:08, César D. Rodas > wrote: >> Hi Peter, >> >> On Thu, 2009-12-17 at 16:33 +, Peter Robinson wrote: >>> >> >> > I'm looking forward to read clues about how to fix it. >>> >> >> >>> >> >> It sounds suspiciously like a Xv issue. That could be anything >>> >> >> from a >>> >> >> missing kernel module to a X driver bug. Out of interest can you >>> >> >> play >>> >> >> video using totem? Possibly record a video using a XO-1 with the >>> >> >> working 802 build and see if it will play on one with the F11 >>> >> >> build. >>> >> >> That would rule out that issue, or possibly we could craft up a >>> >> >> gstreamer pipeline that takes the output of the camera and >>> >> >> displays it >>> >> >> on the screen. Let me know how you go with the totem test and then >>> >> >> we'll see where we can take it from there, if that works I can >>> >> >> work >>> >> >> out what the pipeline would need to be to test that raw. >>> >> > >>> >> > Well, I've tried what you've suggested me, and it has the same >>> >> > problem. >>> >> > >>> >> > $ totem /media/34F7-79FD/11-Music-Painter\ \(medium\).ogg >>> >> > >>> >> > Gdk-ERROR **: The program 'totem' received an X Window System >>> >> > error. >>> >> > This probably reflects a bug in the program. >>> >> > The error was 'BadAlloc (insufficient resources for operation)'. >>> >> > (Details: serial 101 error_code 11 request_code 131 minor_code >>> >> > 19) >>> >> > (Note to programmers: normally, X errors are reported >>> >> > asynchronously; >>> >> > that is, you will receive the error a while after causing it. >>> >> > To debug your program, run it with the --sync command line >>> >> > option to change this behavior. You can then get a meaningful >>> >> > backtrace from your debugger if you break on the gdk_x_error() >>> >> > function.) >>> >> > aborting... >>> >> > aborted >>> >> > >>> >> > >>> >> > Is this output helping somehow? Is there a way I can help out to >>> >> > fix it? >>> >> >>> >> Yes, it looks like an X bug. I had a similar issue previously with >>> >> another X driver. To get a proper backtrace using GDB can you do the >>> >> following, this will then allow us to file a bug. >>> >> >>> >> Run gdb and then from the gdb prompt run the following commands. If >>> >> gdb isn't installed you'll need to do a 'yum install -y gdb'. You'll >>> >> probably need to install quite a few debuginfo packages to ensure we >>> >> get a useful backtrace but if you post the backtrace first we can >>> >> work >>> >> out what we need. >>> >> >>> >> (gdb) exec-file totem --sync >>> >> (gdb) break gdk_x_error() >>> >> (gdb) r >>> >> >>> >> You'll then get totem come up. Try and play the video as before and >>> >> you'll have it crash. The run the following with gdb >>> >> >>> >> (gdb) thread apply all bt >>> >> >>> >> and paste the complete output into a file and put it somewhere I can >>> >> see it (it might be somewhat large). You can see a sample one from an >>> >> issue I had with the nouveau driver previously here >>> >> https://bugzilla.redhat.com/attachment.cgi?id=369702 >>> >> >>> > GDB complained saying it was missing some packages such as >>> > debuginfo-install totem-2.26.5-1.fc11.i586, but I think it will have >>> > not >>> > side effect since I don't want to debug Totem, I want to debug X >>> > through >>> > it. >>> > >>> > The output file is here >>> > http://oficina.paraguayeduca.org/~crodas/X-totem-debug.log >>> > >>> > Is it useful? What else can we do in order to hunt this bug? >>> >>> Its a start. We need (at least) also the following debuginfo packages. >>> So a 'yum install -y gstreamer-debuginfo >>> gstreamer-plugins-base-debuginfo gstreamer-debuginfo glib2-debuginfo >>> totem-pl-parser-debuginfo glibc-debuginfo gtk2-debuginfo >>> libX11-debuginfo xorg-x11-server-debuginfo' >> Thanks for the clue, I've installed those missing packages and I re-run >> the debugger, >> >> http://oficina.paraguayeduca.org/~crodas/X-totem-debug-1.log >> >> Please let me know if I need to do something else to debug better. > > Hi, if you do 'bt full' instead of just bt, it will print some more > stuff and we may be able to see which values are inside the > xvimagesink arg. > > Regards, > > Tomeu > >>> >>> That should fill out the rest of the debuginfo to make the back trace >>> more useful. >>> >>> Regards, >>> Peter >>> >> >> Regards, >> >> ___ >> Devel mailing list >> Devel@lists.laptop.org >> http://lists.laptop.org/listinfo/devel >> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Little issue with Midore
Hello, On Thu, 17 Dec 2009 16:38:03 -0300, César "D. Rodas" wrote: > Hello All, > > In the FC-11, The Midore Browser comes as the default browser. It looks > good so far, but it has a little bug, well it is not a proper bug, the > font-size is too big displaying messages. s/Midore/Midori/g :-) When I said "messages" before, I meant "error messages". In order to reproduce it, just open a non valid URL. > > As I said before, it is not a proper bug, and I fixed it by setting the > default font size to 6px, in the ~/.config/midori/config, and it looks > better. Is there a way to set this configuration by default?, I think it > could be done in the RPM itself, in a %post stage. I might be wrong. If > I'm not wrong, who is takes care of Midore (or perhaps Gnome) packaging? > > Even though Sugar is our target desktop we want everything to (sort of) > work if some kid chooses to try out Gnome. > > > Best regards > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel Regards, ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
