Bug 252951 - Crash in File "/usr/lib64/python2.5/site-packages/miro/app.py", line 746, in _finishStartup
Summary: Crash in File "/usr/lib64/python2.5/site-packages/miro/app.py", line 746, in ...
Alias: None
Product: Fedora
Classification: Fedora
Component: Miro   
(Show other bugs)
Version: 7
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Thorsten Scherf
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-08-16 08:41 UTC by Allan Engelhardt
Modified: 2008-08-02 23:40 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-25 04:26:13 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Output from application. (4.84 KB, text/plain)
2007-08-16 08:41 UTC, Allan Engelhardt
no flags Details
Output as described in Comment #2 (11.91 KB, text/plain)
2007-08-16 08:59 UTC, Allan Engelhardt
no flags Details
See Comment #4 (2.12 KB, application/octet-stream)
2007-08-16 09:06 UTC, Allan Engelhardt
no flags Details

Description Allan Engelhardt 2007-08-16 08:41:37 UTC
Description of problem:
Miro crashes.
(Secondary problem: after crash, Miro will not exit)

Version-Release number of selected component (if applicable): Miro.x86_64

How reproducible: (not sure)

Steps to Reproduce:
1. $ rm -r ~/.miro ~/.gconf/apps/miro/
2. $ miro > /tmp/miro.1 2>&1
3. ... wait a long time, then exit
4. $ miro > /tmp/miro.2 2>&1
5. ... wait, then exit ...
6. $ miro > /tmp/miro.2 2>&1

Actual results:

INFO     App:        Miro
Publisher:  Participatory Culture Foundation
Platform:   gtk-x11
Python:     2.5 (r25:51908, Apr 10 2007, 10:27:40) 
[GCC 4.1.2 20070403 (Red Hat 4.1.2-8)]
Py Path:    ['/usr/lib64/python2.5/site-packages/miro', '/usr/bin',
'/usr/lib64/python25.zip', '/usr/lib64/python2.5',
'/usr/lib64/python2.5/plat-linux2', '/usr/lib64/python2.5/lib-tk',
'/usr/lib64/python2.5/lib-dynload', '/usr/lib64/python2.5/site-packages',
Version:    0.9.8-svn
Serial:     20070719000
Revision:   unknown
Time:       Thu Aug 16 09:36:26 2007
When:       while finishing starting up

Traceback (most recent call last):
  File "/usr/lib64/python2.5/site-packages/miro/app.py", line 746, in _finishStartup
line 165, in setVolume
    volumeScale = app.controller.frame.widgetTree['volume-scale']
AttributeError: MainFrame instance has no attribute 'widgetTree'

Call stack
  File "/usr/lib64/python2.5/threading.py", line 460, in __bootstrap
  File "/usr/lib64/python2.5/threading.py", line 440, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.5/site-packages/miro/eventloop.py", line 277, in loop
  File "/usr/lib64/python2.5/site-packages/miro/eventloop.py", line 134, in
  File "/usr/lib64/python2.5/site-packages/miro/eventloop.py", line 66, in dispatch
    util.trapCall(when, self.function, *self.args, **self.kwargs)
  File "/usr/lib64/python2.5/site-packages/miro/app.py", line 656, in <lambda>
    eventloop.addIdle(lambda :self._finishStartup(gatheredVideos), "Finishing
  File "/usr/lib64/python2.5/site-packages/miro/app.py", line 819, in _finishStartup
    util.failedExn("while finishing starting up")
  File "/usr/lib64/python2.5/site-packages/miro/util.py", line 149, in failedExn
    failed(when, withExn = True, **kwargs)

Current: Event Loop
 - MainThread
 - ThreadPool - 0 [Daemon]
 - ThreadPool - 2 [Daemon]
 - Event Loop
 - ThreadPool - 1 [Daemon]

INFO     ----- END OF CRASH REPORT -----

Expected results:

Additional info: (This is Miro from updates-testing)

Comment 1 Allan Engelhardt 2007-08-16 08:41:37 UTC
Created attachment 161636 [details]
Output from application.

Comment 2 Allan Engelhardt 2007-08-16 08:58:40 UTC
Some sort of crash appears to be reproducible.  This time I got

/usr/bin/miro: line 2: 32750 Segmentation fault     
LD_LIBRARY_PATH=/usr/lib64/firefox- miro.real

at exit time from

1. $ rm -r ~/.miro ~/.gconf/apps/miro/
2. $ miro > /tmp/miro.1 2>&1
3. Video->Quit
4. ... wait a long time; see Bug 252944
5. $ miro > /tmp/miro.2 2>&1
6. Video->Quit and then wait
7. $ miro > /tmp/miro.3 2>&1
8. Video->Quit and then wait

There does not appear to be anything else interesting in the last output file,
but I will attach it.

Comment 3 Allan Engelhardt 2007-08-16 08:59:55 UTC
Created attachment 161637 [details]
Output as described in Comment #2

Comment 4 Allan Engelhardt 2007-08-16 09:04:53 UTC
And after Comment #2, Miro will not run but always dies on the segmentation
fault.  I don't know if this should move to a different bug?

The output from

9. $ miro > /tmp/miro.4 2>&1

will be attached FYI.  No Video->Quit step required here.

Comment 5 Allan Engelhardt 2007-08-16 09:06:03 UTC
Created attachment 161638 [details]
See Comment #4

Comment 6 Jack Deslippe 2007-08-31 06:16:22 UTC

This seems related to my bug report -
https://bugzilla.redhat.com/show_bug.cgi?id=253046 - at least the crash report
in your first comment is similar.  I have been going crazy because I thought I
was the only one with this problem (miro works find so far on another computer
of mine).  

Comment 7 Jack Deslippe 2007-10-03 04:09:41 UTC
I just tried miro 9.9.1 from getmiro.org it seems to have fixed this problem for me.

Comment 8 Alex Lancaster 2007-11-17 02:47:59 UTC
(In reply to comment #7)
> I just tried miro 9.9.1 from getmiro.org it seems to have fixed this problem
for me.

Can you reproduce this bug with the latest Miro in F-7 (not the getmiro.org
version) which is (yum update)

Comment 9 Brian Powell 2008-04-25 04:26:13 UTC
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there have not been any
updates to the report since thirty (30) days or more since we
requested additional information, we're assuming the problem
is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.

Setting status to "CLOSED INSUFFICIENT_DATA".  If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested, 
please feel free to reopen the bug report.

Thank you in advance.

Note that maintenance for Fedora 7 will end 30 days after the GA of Fedora 9.

Note You need to log in before you can comment on or make changes to this bug.