[gst-devel] irc excerp about memory corruption

[vishnu at pobox.com]

<vishnu> wtay: -finstrument-functions doesn't seem very accurate.
sometimes it shows impossible traces
<wtay> oh
<vishnu> wtay: maybe i don't have the right combination of magic yet
<wtay> maybe some compiler optimisations
<vishnu> wtay: this memory corruption is closely related to concurrency.
there is no corruption if i slow things down enough
<wtay> bah
<wtay> hard to debug
<vishnu> very hard
<vishnu> are u sure the locking in the scheduler is correct?
<wtay> no
<vishnu> imho, there are too many mutexen.  generally, it is better
to start with a single mutex and add finer granularity only if needed.
gstreamer is a tough design
<vishnu> fixing the memory leaks makes the corruption more apparent.
i think the corruption was hiding in leaked blocks
<wtay> how can you know the corruption is not caused by a plugin?
<vishnu> sure, it could be a plugin
<vishnu> the plugins look fairly sane, in general.  mostly they might
have array overruns, but electric fence didn't find anything
<vishnu> the plugins are not written with concurrency in mind, they just
operate on their own unshared data, so it doesn't seem likely
<wtay> what is the symptom of the memory corruption?
<vishnu> mcheck (from glibc) claims "mcheck: memory clobbered before
allocated block"
<vishnu> so that means ... anything :-)
<wtay> no indication where?
<vishnu> wtay: i'm trying to narror down on the problem with this stack
trace stuff
<vishnu> wtay: once mcheck detects a problem, it is quite a long time
after the corruption already happened
<wtay> hmm
<vishnu> wtay: if i can't narror it down much then i'll restructure the
code to use fewer mutexen.  that's the only way to eventually fix things,
unless you have a better idea
<vishnu> omega might hate the idea of encapsulation, but memory corruption
means that the current code base is worthless for professional use
<wtay> no, it just means that it is not bugfree yet
<vishnu> still, i like the gstreamer design a lot .. so
<vishnu> wtay: sure, it's not bug free yet .. but i've had lots of my
own projects die because they became undebuggable
<wtay> I'm a master debugger :) that's how I write code :)
<vishnu> wtay: heh, good for you.  i'm not that good.  my preferrence
is to avoid introducing bugs in the first place
<wtay> yeah.. that's my goal too.. it's just nearly impossible
<vishnu> wtay: it's not impossible.  glib/gtk are very close to bug-less
<wtay> yeah, they don't deal with multiple threads..
<vishnu> wtay: heh, maybe i should buy a copy of purify or something
<vishnu> wtay: but none of these tools work so well with threads
.. <grumble>
<vishnu> especially because gstreamer uses threads, there should be more
emphasis on writing clean code

-- 
Victory to the Divine Mother!!
  http://sahajayoga.org