Re: Could anyone give a short info on tracking refcounting bugs?



Hi,

> For higher level languages, where it can be assumed that any
> reference is accounted for by a given 'owner' object, the
> pursuit of imbalanced reference counts can even be automated
> and simplified.

I've just encountered this problem in Vala which is an attempt to make
higher level language. I've added pad probe in GStreamer which
increased ref count of object that owns the probe, so my object wasn't
finalized because its refcount never got to 0. Solution was one-liner
- I've just removed this probe during cleanup procedure and everything
now works fine.

So even in you use higher level language, you can still encounter such
bugs, which are obviously, programmer mistakes but still hard to
track.

Thank you, I'll post bugzilla bug later

m.

However these types of errors should be at least
> diminished if not non-existent in languages that do ref-counting
> for you, by way of automating references using declared variables
> and their scopes... perhaps the instrumentation here needs to
> be available at a low level (compiled into debug versions of
> GObject, like the refdbg tool uses), or additionally... automated
> on a per language binding basis... just food for thought...
>
> Anyway, good luck ;-)
>
> Cheers,
>                -Tristan
>
>>
>> I've also found
>> (https://bugzilla.gnome.org/show_bug.cgi?id=606044#c45) there was a
>> suggestion to add info about using systemtap to docs, but I am unable
>> to volunteer in such case because I had problems in running systemtap:
>>
>> $ stap --ldd debugging/alive.stp -c 'src/myapp -c config.xml'
>> semantic error: probe point mismatch at position 0  (alternatives:
>> __nfs __scheduler __signal __tcpmib __vm _linuxmib _signal _sunrpc
>> _syscall _vfs begin begin(number) end end(number) error error(number)
>> generic ioblock ioblock_trace ioscheduler ioscheduler_trace ipmib
>> irq_handler kernel kprobe kprocess linuxmib module(string) nd_syscall
>> netdev never nfs nfsd perf process process(number) process(string)
>> procfs procfs(string) scheduler scsi signal socket softirq stap
>> staprun sunrpc syscall tcp tcpmib timer tty udp vfs vm workqueue):
>> identifier 'gobject' at debugging/alive.stp:2:7 while resolving probe
>> point gobject.object_new
>>         source: probe gobject.object_new {
>>                       ^
>> semantic error: probe point mismatch at position 0  (alternatives:
>> __nfs __scheduler __signal __tcpmib __vm _linuxmib _signal _sunrpc
>> _syscall _vfs begin begin(number) end end(number) error error(number)
>> generic ioblock ioblock_trace ioscheduler ioscheduler_trace ipmib
>> irq_handler kernel kprobe kprocess linuxmib module(string) nd_syscall
>> netdev never nfs nfsd perf process process(number) process(string)
>> procfs procfs(string) scheduler scsi signal socket softirq stap
>> staprun sunrpc syscall tcp tcpmib timer tty udp vfs vm workqueue):
>> identifier 'gobject' at :5:7 while resolving probe point
>> gobject.object_finalize
>>         source: probe gobject.object_finalize {
>>                       ^
>> Pass 2: analysis failed.  Try again with another '--vp 01' option.
>>
>>
>> script was:
>>
>> global alive
>> probe gobject.object_new {
>>  alive[type]++
>> }
>> probe gobject.object_finalize {
>>  alive[type]--
>> }
>> probe end {
>>   printf ("Alive objects: \n")
>>   foreach (a in alive) {
>>    if (alive[a] > 0)
>>      printf ("%d\t%s\n", alive[a], a)
>>   }
>> }
>>
>>
>> --
>> Marcin Lewandowski


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]