Re: [Tracker] tracker-extract crashes in GLib: gmem.c:168: failed to allocate 2330172 bytes

[Martyn Russell <martyn lanedo com>]

On 12/05/14 14:55, Ralph Böhme wrote:
> Hi Martyn

Hi,

> Am 12.05.2014 um 15:19 schrieb Martyn Russell <martyn lanedo com>:
>
> > On 12/05/14 14:11, Ralph Böhme wrote:
> > > Hi all,
> >
> > Hi Ralph,
> >
> > > I have no idea why the realloc() fails in glib. My first thought was
> > > that there may be a memory leek somewhere, but checking this with
> > > Solaris libumem didn't come up with any serios leaks:
> > >
> > > root beast:~# mdb /opt/csw/libexec/tracker-extract
> > > /var/cores/core.tracker-extract.2763 Loading modules: [ libumem.so.1
> > > libc.so.1 ld.so.1 ]
> > > > ::findleaks
> > > CACHE     LEAKED   BUFCTL CALLER 080c9590       1 080e7350
> > > libglib-2.0.so.0.4000.0`g_mutex_impl_new+0x23
> > > ------------------------------------------------------------------------
> > >
> > > Total       1 buffer, 32 bytes

Ha.

> > > Go figure. :( Ideas?

I don't really have much expertise on Solaris, not since my youth and it 
wasn't pleasant either :(

> > Does it happen each time you index a particular file or is the file
> > itself not important?
>
> these are actuall all the same files. :)

[snip]

> The crash is always happening at a different file.
>
> > I.e. is it an accumulative effect or isolated to one case?
>
> Some sort of accumulative effect.

I was going to suggest perhaps you disable the GSLICE allocator and see 
if that has any effect here. You can do that using:

  export G_SLICE=always-malloc

But I don't expect that to make any difference to be fair.

I would personally start with a process of elimination, commenting out 
code to find out what the real cause is, unless you have other tools you 
can use like Valgrind to give you more details?

Sorry I can't be of more help!

--
Regards,
Martyn

Founder & Director @ Lanedo GmbH.
http://www.linkedin.com/in/martynrussell