After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 767906 - gst-validate-launcher Application timed out: 30 secs
gst-validate-launcher Application timed out: 30 secs
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-devtools
1.6.3
Other Linux
: Normal critical
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 767720 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2016-06-21 08:47 UTC by yvonne.chen
Modified: 2018-05-04 09:24 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
gst-validate logs (3.91 KB, text/plain)
2016-06-21 08:47 UTC, yvonne.chen 		Details

Description yvonne.chen 2016-06-21 08:47:35 UTC 
Created attachment 330118 [details]
gst-validate logs

Hi GUYS 
 I got Application timed out: 30 secs with command
gst-validate-launcher -M /mnt/gst-validate --generate-media-info -t validate.file.playback.change_state_intensive.mp3_h264_0_mp4 

I got final report  as follows

=============
Final Report:
=============
validate.file.playback.change_state_intensive.mp3_h264_0_mp4: Timeout 'Application timed out: 30 secs'
       You can reproduce with: GST_GL_XINITTHREADS=1 DISPLAY=:0 GST_VALIDATE_SCENARIO=change_state_intensive gst-validate-1.0  playbin uri=file:///mnt/gst-validate/gst-integration-testsuites/medias/defaults/mp4/mp3_h264.0.mp4 --set-media-info "/mnt/gst-validate/gst-integration-testsuites/medias/defaults/mp4/mp3_h264.0.mp4.media_info"
       You can find logs in:
             - /mnt/gst-validate/logs/validate/file/playback/change_state_intensive/mp3_h264_0_mp4
             - /mnt/gst-validate/logs/validate/file/playback/change_state_intensive/mp3_h264_0_mp4.validate.logs
             - /mnt/gst-validate/logs/validate/file/playback/change_state_intensive/mp3_h264_0_mp4.gstdebug


But, when I reproduce with comand reproduce command GST_GL_XINITTHREADS=1 DISPLAY=:0 GST_VALIDATE_SCENARIO=change_state_intensive gst-validate-1.0  playbin uri=file:///mnt/gst-validate/gst-integration-testsuites/medias/defaults/mp4/mp3_h264.0.mp4 --set-media-info "/mnt/gst-validate/gst-integration-testsuites/medias/defaults/mp4/mp3_h264.0.mp4.media_info"

the test is passed . Who can give me some explaination?

attached is logs
Comment 1 Sebastian Dröge (slomo) 2016-06-21 08:57:30 UTC 
Please provide a full GStreamer debug log and a backtrace of all threads when it hangs. Also does this only happen with your custom decoders, if so you'll have to work on fixing them.
Comment 2 yvonne.chen 2016-06-21 10:02:16 UTC 
attached is full debug log  I got . how to get the backtrace of all threads？

I run two different commands under same environment.
I found nothing hang, I redirect the log with -r stderr , all log prints out smoothly. And the final result with timeout occurs.
Comment 3 Sebastian Dröge (slomo) 2016-06-21 11:11:45 UTC 
thread apply all bt
In gdb ath the moment when you want it to print tgem
Comment 4 Sebastian Dröge (slomo) 2016-06-21 11:12:27 UTC 
Also does it only happen with your customs codecs or also eg gst-libav?
Comment 5 Edward Hervey 2018-05-04 09:23:03 UTC 
If you manage to reproduce with latest stable version, please re-open this bug and provide new logs (which should include backtraces).
Comment 6 Edward Hervey 2018-05-04 09:24:44 UTC 
*** Bug 767720 has been marked as a duplicate of this bug. ***