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 123249 - [PATCH] spider doesn't work with file size smaller than 150 Ko
[PATCH] spider doesn't work with file size smaller than 150 Ko
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins
0.6.x
Other Linux
: High major
: 0.8.0
Assigned To: Ronald Bultje
GStreamer Maintainers
: 125479 128056 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-09-25 21:45 UTC by Jeremy Simon
Modified: 2005-08-15 01:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Possible fix (2.08 KB, patch)
2003-10-03 08:40 UTC, Ronald Bultje
none Details | Review
new try (2.29 KB, patch)
2003-10-03 13:41 UTC, Ronald Bultje
none Details | Review
current patch, not 100% working :( (2.93 KB, patch)
2003-10-06 10:07 UTC, Ronald Bultje
none Details | Review
/me ducks (2.60 KB, patch)
2003-10-06 13:08 UTC, Ronald Bultje
none Details | Review

Description Jeremy Simon 2003-09-25 21:45:54 UTC
There is a problem with spider if the file size is smaller that the
*bufsizelimit* in gstspideridentity.c
Comment 1 Ronald Bultje 2003-10-02 12:53:03 UTC
I'm marking this as a blocker for 0.6.4. Not to annoy you, but simply
because we need this fixed before 0.6.4 comes out.

I'll look into this a.s.a.p.
Comment 2 Ronald Bultje 2003-10-03 08:40:04 UTC
Created attachment 20452 [details] [review]
Possible fix
Comment 3 Ronald Bultje 2003-10-03 08:40:33 UTC
Does the above patch fix it? It properly handles EOS during buffer
build-up.
Comment 4 Christophe Fergeau 2003-10-03 13:03:42 UTC
I applied the patch and am getting crashes 
  • #0 gst_spider_identity_sink_loop_type_finding
    at gstspideridentity.c line 450
  • #1 loop_group_schedule_function
    at gstoptimalscheduler.c line 995
  • #2 schedule_group
    at gstoptimalscheduler.c line 844
  • #3 gst_opt_scheduler_schedule_run_queue
    at gstoptimalscheduler.c line 877
  • #4 schedule_chain
    at gstoptimalscheduler.c line 922
  • #5 gst_opt_scheduler_iterate
    at gstoptimalscheduler.c line 1916
  • #6 gst_scheduler_iterate
    at gstscheduler.c line 732
  • #7 gst_bin_iterate_func
    at gstbin.c line 902
  • #8 gst_bin_iterate
    at gstbin.c line 947

The stack trace doesn't make much sense to me though :(
Comment 5 Ronald Bultje 2003-10-03 13:41:50 UTC
Created attachment 20454 [details] [review]
new try
Comment 6 Ronald Bultje 2003-10-03 13:42:30 UTC
There was a missing check for whether something is NULL causing this.
The above should fix that.
Comment 7 Thomas Vander Stichele 2003-10-05 14:47:42 UTC
apoc, could you comment on the new fix ?
Comment 8 Thomas Vander Stichele 2003-10-05 17:11:57 UTC
I tried the fix myself; it doesn't hang my machine for a long time
anymore with:

(process:27628): GStreamer-CRITICAL **: file gstdata.c: line 239
(gst_data_unref): assertion `GST_DATA_REFCOUNT_VALUE (data) > 0' failed
 

but instead it doesn't play, and gives me a lot of
 GStreamer-WARNING **: pull on pad filesrc0:src but it is not active
Comment 9 Ronald Bultje 2003-10-06 10:02:47 UTC
This is starting to get really annoying...

I've got the fix as far as not to hang the app. However, I cannot get
spider to understand that it should *properly* EOS *some* elements
inside it. I just don't understand spider well enough, I suppose.

Issue is as follows: as soon as the typefinder in spider fetches EOS,
it should typefind with the buffer it has and then push that buffer
forward, followed by EOS. All this works. However, on EOS, spider
calls gst_element_set_eos () on all its elements inside it (i.e.
everything). This is wrong, imo, it should just set it on the first
element in its own chain of elements.

Anyway, even if I comment that whole part out and just push EOS to
ident->src in the chainfunc of spider, weird stuff happens. I get
warnings such as "(process:15180): GStreamer-WARNING **: pull on pad
mad0:src but it is not active" and fail to understand why from this
point on. The whole pipeline should be set to EOS, but that doesn't
happen... This is weird, because I'm following the exact same path
that a >150kB file would follow, and that still works. I'm really
missing a point here...

Apparently, I'm badly misunderstanding something here.

What I *think* is going on: everything in spider is one thread, and
with opt, that kills several things. It means that if I push my buffer
inside spider and then push another, both will be queued internally
and, when the loopfunc/chainfunc of spider returns, handled by the
next element. *However*, spider has then already set EOS on those
elements, which is why I don't want it to call gst_element_set_eos()
on its children. But it does, somehow. This is proven by the fact that
my fix works if I use the basic scheduler instead of the opt one
(here, every element is its own thread).

Anyway, this is complicated. I don't know how to fix it easily.

Help! ;).
Comment 10 Ronald Bultje 2003-10-06 10:07:44 UTC
Created attachment 20492 [details] [review]
current patch, not 100% working :(
Comment 11 Ronald Bultje 2003-10-06 13:07:04 UTC
I found the problem. The scheduler (opt) puts the decoder and filesrc
in the same group (thread), which means that the next call to filesrc
will hang because filesrc (or whichever source) is in PAUSED (eos).

I've got a pretty horrible workaround for this, please don't kill me
right away but let me first explain that this is the only way I could
fix this...
Comment 12 Ronald Bultje 2003-10-06 13:08:16 UTC
Created attachment 20500 [details] [review]
/me ducks
Comment 13 Thomas Vander Stichele 2003-10-09 14:50:03 UTC
postponing bug
Comment 14 David Schleef 2003-10-31 04:04:44 UTC
*** Bug 125479 has been marked as a duplicate of this bug. ***
Comment 15 David Schleef 2003-12-02 01:29:16 UTC
*** Bug 128056 has been marked as a duplicate of this bug. ***
Comment 16 alexander.winston 2004-01-02 21:57:52 UTC
Adding the PATCH keyword and upgrading the priority to High due to the
attached patches.
Comment 17 Ronald Bultje 2004-01-02 23:37:11 UTC
This is definately not a blocker bug. I'm moving it back to 'major'.

Note that (IIRC) HEAD CVS doesn't have this issue. Only 0.6.x does.
Comment 18 alexander.winston 2004-01-05 03:50:08 UTC
Ronald: Did you mean to remove the PATCH keyword?
Comment 19 Ronald Bultje 2004-01-05 09:53:03 UTC
Yes, because the patch is already in CVS for as far it's worth applying.
Comment 20 David Schleef 2004-03-18 21:40:04 UTC
This appears to be fixed in 0.8.0.  If not, someone will reopen it, right?