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 339872 - filesrc can't work in pull mode (XScale)
filesrc can't work in pull mode (XScale)
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other All
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-04-27 02:03 UTC by Lily Gao
Modified: 2006-05-09 10:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
when I don't set debug level to 5 (144 bytes, application/x-gzip-compressed)
2006-04-27 08:57 UTC, Lily Gao
Details
when i set debug level to 5, it cause segmentation falut, log attached (10.37 KB, application/x-gzip-compressed)
2006-04-27 08:59 UTC, Lily Gao
Details

Description Lily Gao 2006-04-27 02:03:26 UTC
Please describe the problem:
the same source code works well at x86 both win32 and linux. but when porting 
to xscale architecture board, when check pull range, it returns that it doesn't 
support pull mode.
for example: gst-launch filesrc location=a.mp3 ! myelement ! filesink 
location=test.dat
where myelement is working under pull mode.

Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Luis Villa 2006-04-27 03:39:37 UTC
Looks like you meant this to go against gstreamer. reassigning.
Comment 2 Tim-Philipp Müller 2006-04-27 08:13:39 UTC
Which GStreamer core version is that with?

Could you attach a debug log please?

 $ export GST_DEBUG=*:5
 $ export GST_DEBUG_NO_COLOR=1
 $ gst-launch-0.10 -v filesrc location=test.mp3 ! yourelement ! filesink location=test.dat 2>&1 | gzip > dbg.log.gz

Comment 3 Lily Gao 2006-04-27 08:57:45 UTC
Created attachment 64378 [details]
when I don't set debug level to 5
Comment 4 Lily Gao 2006-04-27 08:59:05 UTC
Created attachment 64379 [details]
when i set debug level to 5, it cause segmentation falut, log attached
Comment 5 Lily Gao 2006-04-27 09:10:29 UTC
I tred both core 0.10.4 and 0.10.3, all could not work. 
Comment 6 Lily Gao 2006-04-27 09:13:43 UTC
(In reply to comment #2)
> Which GStreamer core version is that with?
0.10.4
> Could you attach a debug log please?
>  $ export GST_DEBUG=*:5
>  $ export GST_DEBUG_NO_COLOR=1
>  $ gst-launch-0.10 -v filesrc location=test.mp3 ! yourelement ! filesink
> location=test.dat 2>&1 | gzip > dbg.log.gz

when i don't set debug level to 5, as i discribed above
but when i do as you said, it caused segmentation fault.
Comment 7 Tim-Philipp Müller 2006-04-27 10:45:48 UTC
(In reply to comment #6)
 
> when i don't set debug level to 5, as i discribed above
> but when i do as you said, it caused segmentation fault.
 
Could you please post a stack trace of where the segmentation fault occurs then?

You should use the latest core release (0.10.4, might also be worth trying the 0.10.5 prerelease or CVS HEAD).
Comment 8 Tim-Philipp Müller 2006-04-28 17:01:04 UTC
You could also try making a debug log with GST_DEBUG=*:4  (instead of *:5), maybe it doesn't crash then.
Comment 9 Lily Gao 2006-04-29 06:07:25 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > when i don't set debug level to 5, as i discribed above
> > but when i do as you said, it caused segmentation fault.
> Could you please post a stack trace of where the segmentation fault occurs
> then?
pgd = c3bc0000
[00000000] *pgd=83700011, *pte=00000000, *ppte=00000000
PC is at 0x404ef128
LR is at 0x4042f00c
pc : [<404ef128>]    lr : [<4042f00c>]    Not tainted
sp : befff0f4  ip : 00000000  fp : befff4ec
r10: 4046b808  r9 : 00033218  r8 : 00000000
r7 : 0000000f  r6 : 00000073  r5 : 00000000  r4 : 0000006c
r3 : 000000d8  r2 : befff170  r1 : 00032c48  r0 : fffffff8
Flags: nZcv  IRQs on  FIQs on  Mode USER_32  Segment user
Control: 400397F  Table: 83BC0018  DAC: 00000015
Segmentation fault
> You should use the latest core release (0.10.4, might also be worth trying the
> 0.10.5 prerelease or CVS HEAD).
I used the latest core release 0.10.4

Comment 10 Lily Gao 2006-04-29 06:08:32 UTC
(In reply to comment #8)
> You could also try making a debug log with GST_DEBUG=*:4  (instead of *:5),
> maybe it doesn't crash then.

GST_DEBUG=*:4, 3,5 all crash
Comment 11 Tim-Philipp Müller 2006-04-29 12:25:06 UTC
> > Could you please post a stack trace of where the segmentation fault occurs
> > then?
>
> pgd = c3bc0000
> [00000000] *pgd=83700011, *pte=00000000, *ppte=00000000
> PC is at 0x404ef128
> LR is at 0x4042f00c
> pc : [<404ef128>]    lr : [<4042f00c>]    Not tainted
> sp : befff0f4  ip : 00000000  fp : befff4ec
> r10: 4046b808  r9 : 00033218  r8 : 00000000
> r7 : 0000000f  r6 : 00000073  r5 : 00000000  r4 : 0000006c
> r3 : 000000d8  r2 : befff170  r1 : 00032c48  r0 : fffffff8
> Flags: nZcv  IRQs on  FIQs on  Mode USER_32  Segment user
> Control: 400397F  Table: 83BC0018  DAC: 00000015
> Segmentation fault
> > You should use the latest core release (0.10.4, might also be worth trying the
> > 0.10.5 prerelease or CVS HEAD).
> I used the latest core release 0.10.4

Thanks for that, but I'm afraid it's not really that useful to us. By 'stack trace' I mean what gdb prints when you type 'bt' there after a crash. Please see

 http://live.gnome.org/GettingTraces#gdb-only

for more details (assuming gdb works on that platform). It would be best if you compiled GStreamer with debugging symbols for this (ie. pass --enable-debug to ./configure).
Comment 12 Tim-Philipp Müller 2006-05-03 08:44:03 UTC
Any chance bug #332841 is what's causing the crashes when using GST_DEBUG?
Comment 13 Tim-Philipp Müller 2006-05-09 10:05:50 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!