Bug 213528

Sorry, I was away at a conference.

Does the crash happen only when you attempt to use the re-sizing options?
If we can narrow down under what conditions we can get it to crash repeatedly we
may be able to get the upstream developer to patch the bug.  I have an fc6
system installed now so I can attempt to reconfirm crash conditions, but I can't
garuntee I'll be able to fix it without the upstream developer for istanbul
getting involved.

-jef

I just attempted to reproduce your crash condition and I could not.
Can you make sure you have all the fc6 updates installed and try again.

I was able to make an ogg theora video with record 3d. record mouse and record
sound enabled with quarter width and hieght selected.  I can't actually test if
sound recording is working.. but i did not get a crash.

-jef

I am able to reproduce an almost identical error (see below) by:

1. click "Select Area to Record" in istanbul popup
2. click anywhere in the screen, actually selecting a one pixel wide area (I
wanted to capture _only_ a window and misinterpreted the menu)


[giallu@hal9001 ~]$ istanbul 
DEBUG: final pipeline: istximagesrc name=videosource use-damage=false
show-pointer=false ! video/x-raw-rgb,framerate=10/1 ! videorate !
ffmpegcolorspace ! videoscale method=1 !
video/x-raw-yuv,width=1400,height=1050,framerate=10/1 ! theoraenc ! oggmux
name=mux ! filesink location=/tmp/tmpAUsdzX
SaveWindow with file: /tmp/tmpAUsdzX
(992, 605) - (993, 606)
DEBUG: final pipeline: istximagesrc startx=992 starty=605 endx=992 endy=605
name=videosource use-damage=false show-pointer=false !
video/x-raw-rgb,framerate=10/1 ! videorate ! ffmpegcolorspace ! videoscale
method=1 ! video/x-raw-yuv,width=1,height=1,framerate=10/1 ! theoraenc ! oggmux
name=mux ! filesink location=/tmp/tmpjxCvJB
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/istanbul/main/tray_icon.py", line 56,
in _trayicon_clicked
    self.current_screencast.start_recording()
  File "/usr/lib/python2.4/site-packages/istanbul/main/screencast.py", line 109,
in start_recording
    self._pipeline = gst.parse_launch(final_pipeline)
gobject.GError: could not link videoscale2 to theoraenc1
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/istanbul/main/tray_icon.py", line 62,
in _trayicon_clicked
    self.current_screencast.stop_recording()
  File "/usr/lib/python2.4/site-packages/istanbul/main/screencast.py", line 136,
in stop_recording
    self._vsource.set_state(gst.STATE_NULL)
AttributeError: Screencast instance has no attribute '_vsource'

The mystery deepens... select area is working for me.  I'll attach my example
desktop area vorbis recording i just made for you to take a look at.

So we need to figure out why this works for me and not for you.
Are you on 32bit or 64bit? I'm on 32bit.

Do you have all the available fc6/fe6 updates installed?

What is the exact kernel version you have installed and running
uname -r
and
yum list kernel   
and report back with the line for the installed kernel.

My output:
uname -r: 
2.6.18-1.2798.fc6
yum list kernel:
kernel.i686    2.6.18-1.2798.fc6      installed


What video hardware are you using?

-jef

Created attachment 140975 [details]
Example recording using selection area feature of fc6 istanbul

Example recording using selection area feature of fc6 istanbul

Here are the relevant specs for my system:

[brad@satsuki ~]$ cat /proc/cpuinfo | grep model\ name
model name      : Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz

[brad@satsuki ~]$ lspci | grep VGA
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW
[Radeon Mobility 7500]

[brad@satsuki ~]$ uname -r
2.6.18-1.2798.fc6

The system is fully updated. I think the key lies in figuring out what the first
crash means:

DEBUG: final pipeline: oggmux name=mux ! filesink location=/tmp/tmp-OJbKk
istximagesrc name=videosource show-pointer=false !
video/x-raw-rgb,framerate=10/1 ! videorate ! ffmpegcolorspace ! videoscale
method=1 ! video/x-raw-yuv,width=256,height=192,framerate=10/1 ! theoraenc !
queue ! mux. gconfaudiosrc name=audiosource ! audioconvert ! vorbisenc ! queue !
mux.
Traceback (most recent call last):
  File "/usr/local/lib/python2.4/site-packages/istanbul/main/tray_icon.py", line
56, in _trayicon_clicked
    self.current_screencast.start_recording()
  File "/usr/local/lib/python2.4/site-packages/istanbul/main/screencast.py",
line 109, in start_recording
    self._pipeline = gst.parse_launch(final_pipeline)
gobject.GError: could not link videorate0 to ffmpegcsp0


I've emailed the author but gotten no response. 

Interesting...

[brad@satsuki ~]$ locate ffmpegc
/usr/lib/gstreamer-0.10/libgstffmpegcolorspace.so
/usr/lib/gstreamer-0.8/libgstffmpegcolorspace.so


I have to run now but I will try changing colordephts and see what happens. I'm
currently using "Thousands of Colors" (16-bit?). I'll try changing it later and
see if it makes a difference.

(In reply to comment #4)
> The mystery deepens... select area is working for me.  I'll attach my example
> desktop area vorbis recording i just made for you to take a look at.

Yap. it works (and I can do the same here) but maybe I missed to stress what is
the cuplrit (at least in _my_ case): the error I see is triggered by selecting a
1x1 area to record.

Of course that is a stupid thing to do BUT users often do stupid things :)

> 
> So we need to figure out why this works for me and not for you.
> Are you on 32bit or 64bit? I'm on 32bit.

This is a laptop with a centrino (so 32 bit) processor 1.7 Ghz,

> 
> Do you have all the available fc6/fe6 updates installed?

Yes. And I am using FC/FE/livna repos only. I'm attaching the full pkg list in
this machine

> 
> My output:
> uname -r: 
> 2.6.18-1.2798.fc6
> yum list kernel:
> kernel.i686    2.6.18-1.2798.fc6      installed

same here

> 
> 
> What video hardware are you using?
from lspci -v:
ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] (prog-if 00 [VGA])

from s-c-d:
1400x1050 resolution, millions of colors, radeon driver

Created attachment 140992 [details]
list of packages installed in my PC

In reply to comment #9

Yippie!
I can definitely confirm a crash condition if I make the selected area "too
small."  I don't know how small too small is at the moment..but now that I can
reproduce the crasher I can start playing with gstreamer pipelines outside of
istanbul and try to figure out more specifics and bound the problem space.

My hunch is that there is an inherent limitation on the size of the video
geometry for some of the gstreamer plugins in the pipeline. I'll know more once
I can spin up standalone gstreamer pipelines to use with gst-launch at the
cmdline.   

If that hunch is true the easiest quick fix in istanbul would be to pad the
selected area up to whatever minimum geometry is allowed by the gstreamer
objects.  Can someone help me spin up a prototype patch that does the padding of
the area select? We can play with the pad values in more detail later after I do
more testing.

On top of that maybe we can help the upstream author implement some error
condition checking on the gstreamer pipeline, so istanbul can throw an error
dialog instead of a traceback for other potential crashers related to pipeline
errors.


I still cannot reproduce a crash using the conditions laid out by the original
reporter so far.  The original reporter maybe hitting a related but different
crash condition. 

-jef"slow progress is better than no progress"spsleta

Seeing the crash here with an up to date rawhide (FC7).
I've got a Radeon 9700 Pro with the open source radeon driver, with the driver
in 16 bit depth mode it crashes but it works in 24 bit.
The minimum size bug seems unrelated (from what i can see) to the original
reporters bug.
Brad did this (bumping up the bith depth) solve it for you to?

(In reply to comment #11)
> Seeing the crash here with an up to date rawhide (FC7).
> I've got a Radeon 9700 Pro with the open source radeon driver, with the driver
> in 16 bit depth mode it crashes but it works in 24 bit.
> The minimum size bug seems unrelated (from what i can see) to the original
> reporters bug.
> Brad did this (bumping up the bith depth) solve it for you to?
> 

This sounds like a problem with the underlying gstreamer module that deals with
X capture.  We need to find the cycles to test this with gstreamer pipelines
outside of istanbul so we can narrow down the problem(s).  I just haven't found
the cycles to dig into this and hand you guys back some custom gstreamer
pipelines to run.

-jef

> Brad did this (bumping up the bith depth) solve it for you to?

Interestingly enough, yes. It seems to work now. 

maybe some more info... 

recording a area of half my desktop works 
 
recording the full desktop  causes the following error 

 istanbul
DEBUG: final pipeline: istximagesrc name=videosource show-pointer=false !
video/x-raw-rgb,framerate=10/1 ! videorate ! ffmpegcolorspace ! videoscale
method=1 ! video/x-raw-yuv,width=1024,height=768,framerate=10/1 ! theoraenc !
oggmux name=mux ! filesink location=/tmp/tmpxPplir
SaveWindow with file: /tmp/tmpxPplir
The program 'istanbul' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 46 error_code 11 request_code 140 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.)

Just an update,
I'm working on updating istanbul to 0.2.2
if reported a crash condition in this bug ticket previously can you
take my test rpms for a spin.

You will need both the istanbul and the python-xlib rpms found at
http://jspaleta.thecodergeek.com/Fedora%20SRPMS/istanbul/0.2.2-FC6-test/

I can't do the istanbul update till python-xlib passes review. But the my
locally built rpms should be fine for testing.

-jef

The 0.2.2 version of istanbul has been built and should be available on the
mirrors very shortly. Please retest for this bug with the update and report back.

-jef

When I try to reproduce this bug with Fedora 7, I only get this output:


/usr/lib/python2.5/site-packages/istanbul/main/tray_icon.py:26:
DeprecationWarning: the module egg.trayicon is deprecated; equivalent
functionality can now be found in pygtk 2.10
  import egg.trayicon
DEBUG: final pipeline: oggmux name=mux ! filesink location=/tmp/tmp4tyNj6
istximagesrc name=videosource display-name=:0.0 screen-num=0 !
video/x-raw-rgb,framerate=10/1 ! videorate ! ffmpegcolorspace ! videoscale
method=1 ! video/x-raw-yuv,width=320,height=256,framerate=10/1 ! theoraenc !
queue ! mux. gconfaudiosrc name=audiosource ! audioconvert ! vorbisenc ! queue !
mux.


And the Icon stays at the harddrive Icon, but the cpu idles. I do not know,
where there is the recording or how to acquire it, the icon does not change when
I click on it and there is no context menu anymore.

I used istanbul-0.2.2-2.fc7 on kde.

This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Just to follow up, I think the last problem reported in this bug has finally
been fixed in recent updates to Fedora 8 and Fedora 9.

There was a lingering problem with audio recording that has a patch now and I
have confirmed fix that the F9 zero-day update for istanbul is working for
people.  But we arrived at the patch far too late for the inclusion of F7.

The patched F8 version is heading to stable updates testing right now as well.


-jef

Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.