Bug 6433 - Use after free errors from the coverity checker
Summary: Use after free errors from the coverity checker
Status: RESOLVED INVALID
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Havoc Pennington
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-30 22:26 UTC by Kjartan Maraas
Modified: 2010-09-13 12:36 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Kjartan Maraas 2006-03-30 22:26:16 UTC
Hi.

I'm seeing a lot of use after free errors from dbus in the coverity checker
reports at http://scan.coverity.com/

There's too many of these to be separate cases so I'm trying to track down one
or more root causes for this. So far I've seen this reported after calling the
following functions:

Event freed_arg: Pointer "connection" freed by function
"_dbus_connection_acquire_dispatch" [model]
Also see events: [deref_after_free]
3243 	  _dbus_connection_acquire_dispatch (connection);
Event deref_after_free: Dereferencing freed pointer "connection"
Also see events: [freed_arg]
3244 	  HAVE_LOCK_CHECK (connection);

also:

Event freed_arg: Pointer "connection" freed by function
"_dbus_connection_add_timeout_unlocked" [model]
Also see events: [deref_after_free]
At conditional (1): "_dbus_connection_add_timeout_unlocked == 0" taking false path
782  	  if (!_dbus_connection_add_timeout_unlocked (connection, pending->timeout))
783  	    return FALSE;
784  	  
Event deref_after_free: Dereferencing freed pointer "connection"
Also see events: [freed_arg]
785  	  if (!_dbus_hash_table_insert_int (connection->pending_replies,
786  	                                    pending->reply_serial,
787  	                                    pending))

and:

Event freed_arg: Pointer "pending" freed by function
"_dbus_connection_detach_pending_call_and_unlock" [model]
Also see events: [deref_arg]
908  	  _dbus_connection_detach_pending_call_and_unlock (pending->connection,
pending);
909  	  
910  	  /* Must be called unlocked since it invokes app callback */
Event deref_arg: Dereferencing freed pointer "pending" in call to function
"_dbus_pending_call_notify" [model]
Also see events: [freed_arg]
911  	  _dbus_pending_call_notify (pending);
912  	  dbus_pending_call_unref (pending);

and:

Event alias: aliasing "(pending)->connection" with "connection"
Also see events: [freed_arg][deref_after_free]
2623 	  connection = pending->connection;
2624 	  client_serial = pending->reply_serial;
2625 	
2626 	  /* note that timeout_milliseconds is limited to a smallish value
2627 	   * in _dbus_pending_call_new() so overflows aren't possible
2628 	   * below
2629 	   */
2630 	  timeout_milliseconds = dbus_timeout_get_interval (pending->timeout);
2631 	
2632 	  /* Flush message queue */
Event freed_arg: Pointer "connection" freed by function "dbus_connection_flush"
[model]
Also see events: [alias][deref_after_free]
2633 	  dbus_connection_flush (connection);
2634 	
Event deref_after_free: Dereferencing freed pointer "connection"
Also see events: [alias][freed_arg]
At conditional (1): "1" taking true path
2635 	  CONNECTION_LOCK (connection);

There are many more that look similar, but maybe someone who's more familiar
with the codebase can point me in the right direction already?
Comment 1 Kjartan Maraas 2006-04-24 19:26:26 UTC
Language is a difficult thing. I didn't mean the last sentence the way it reads,
but any pointers would be welcome :)
Comment 2 Stephan Kulow 2006-07-05 06:37:50 UTC
We have them too in our coverity scans ;(
Comment 3 Colin Walters 2008-05-30 17:47:52 UTC
I don't see DBus in the Coverity listings anymore - does anyone know if that means we fixed the issues or they just aren't scanning us?
Comment 4 Kjartan Maraas 2010-09-13 12:36:46 UTC
The Coverity checker didn't really work out for us, so I'm closing this report.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.