summaryrefslogtreecommitdiff
path: root/modules/dbus.c
Commit message (Collapse)AuthorAgeFilesLines
* Trace signal closures from the object instead of the context keep-aliveGiovanni Campagna2012-06-201-6/+7
| | | | | | | | | | | | Implement tracing for GObjects and use it so that signal handlers are rooted to the objects they're connected, and not the global object. This means that if the object goes away and the only thing referring to it is the handler function, it is recognized as a cycle by the GC and collected, reducing memory leaks. Other closures, as well as callback trampolines and vfuncs, are still rooted in the usual way. https://bugzilla.gnome.org/show_bug.cgi?id=678504
* Fix various memory leaksJasper St. Pierre2012-05-251-1/+1
| | | | | | Found with make valgrind-check. We should run it more often. https://bugzilla.gnome.org/show_bug.cgi?id=676843
* Remove JSFUN_FAST_NATIVEJasper St. Pierre2011-11-281-17/+17
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=664360
* Remove All Rights Reserved. for code originating from LitlJohan Dahlin2011-07-251-1/+1
|
* Quiet a bunch of set-but-unused variable warningsColin Walters2011-03-101-4/+0
|
* dbus: fix memory leak in DBus.bus.acquire_nameGJS_0_7_11Tommi Komulainen2011-02-221-0/+2
| | | | | | | | | | | | | | | | | | | | As reported by valgrind-check. 14 bytes in 1 blocks are definitely lost in loss record 301 of 1,270 at 0x4024F20: malloc (vg_replace_malloc.c:236) by 0x40FAD63: g_malloc (gmem.c:164) by 0x4113C18: g_strdup (gstrfuncs.c:102) by 0x4037F11: gjs_string_get_ascii (jsapi-util-string.c:272) by 0x5BE20D4: gjs_js_dbus_acquire_name (dbus.c:1178) by 0x420A016: js_Interpret (in /opt/big/lib/libmozjs.so) by 0x4213700: js_Execute (in /opt/big/lib/libmozjs.so) by 0x41B8894: JS_EvaluateUCScriptForPrincipals (in /opt/big/lib/libmozjs.so) by 0x41B897E: JS_EvaluateUCScript (in /opt/big/lib/libmozjs.so) by 0x41BCF2F: JS_EvaluateScript (in /opt/big/lib/libmozjs.so) by 0x4031BE3: gjs_context_eval (context.c:912) by 0x4031EA7: gjs_context_eval_file (context.c:993) https://bugzilla.gnome.org/show_bug.cgi?id=639167
* Fix mis-paired calls to JS_AddRoot/JS_RemoveRootOwen W. Taylor2010-12-101-0/+2
| | | | | | | Fix a case where we would never remove a root we added and another place where we removed a root twice in a cleanup path. https://bugzilla.gnome.org/show_bug.cgi?id=636928
* Follow on to last patch to clean up goto handlingMarc-Antoine Perennou2010-12-021-26/+20
|
* xulrunner2: Conditionally handle availability of JS_GetStringBytesMarc-Antoine Perennou2010-12-021-65/+126
| | | | | | | | | | | | | | | This upstream mozilla commit: http://hg.mozilla.org/mozilla-central/changeset/f7171a41a816 removed JS_GetStringBytes in favor of an API which requires the caller to allocate. We were using this function in a number of places, and most of those now need to malloc() with the new API. Rather than trying to use JS_GetStringBytes as "const", and malloc() only with the new API, wrap it and always malloc()/free(). Based on a patch originally from Sardem FF7 <sardemff7.pub@gmail.com>. https://bugzilla.gnome.org/show_bug.cgi?id=635707
* xulrunner2: Get rid of gjs_string_get_asciiMarc-Antoine Perennou2010-12-011-15/+15
| | | | | | | | In xulrunner2, JS_GetStringBytes has been removed, we will now always need a context. We won't be able to use gjs_string_get_ascii anymore, port each call to it to gjs_string_get_ascii_checked Btw, rename gjs_string_get_ascii_checked to gjs_string_get_ascii https://bugzilla.gnome.org/show_bug.cgi?id=635707
* Port more custom functions to be "fast" nativesGJS_0_7_7Colin Walters2010-11-121-76/+82
| | | | | | | These were missed in the big conversion to fast natives in c78646ed3f24bd915c7cfe4aca https://bugzilla.gnome.org/show_bug.cgi?id=632159
* Separate "basic" API from "embedder/module" APIColin Walters2010-10-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | Previously <gjs/gjs.h> pulled in a lot of stuff, and in particular, <gjs/jsapi-util.h>, which in turn required <jsapi.h>. For a simple app that wants to embed GJS we should not be pulling that in. So <gjs/gjs.h> is now the "simple" API that actually just includes <gjs/context.h>, suitable for creating a context and calling eval(). <gjs/gjs-module.h> is now equivalent to the old <gjs/gjs.h>, it pulls in the world. Also, create a corresponding .pc file, gjs-internals-1.0.pc. This one includes mozjs as Requires, and adds the requisite Cflags. For gjs-1.0.pc, change the Requires to simply be gobject-2.0. Conceptually, a gjs-devel RPM should not Require gobject-introspection-devel or xulrunner-devel, and a simple embedder program just using gjs_context_new()/gjs_context_eval() should not have DT_NEEDED on gobject-introspection-1.0.so or mozjs.so. https://bugzilla.gnome.org/show_bug.cgi?id=632795
* Use separate SetPrototype() and SetParent callsColin Walters2010-09-301-1/+8
| | | | | | | | | In XULRunner 1.9.3, passing a custom prototype or parent to JS_ConstructObject for Object fails, so work around with a separate calls to SetPrototype()/SetParent(). See https://bugzilla.mozilla.org/show_bug.cgi?id=599651. https://bugzilla.gnome.org/show_bug.cgi?id=622896
* Replace call context with a concept of "current context"Owen W. Taylor2010-09-301-6/+18
| | | | | | | | | | | | | | | | | | | | | | | Using multiple nested contexts on the same thread isn't normal usage of Spidermonkey and triggers bugs in Spidermonkey that might not be caught in upstream testing. (It is theoretically supported, to at least some extent.) When calling a callback, the best context to use is the current context. If that's not available, then using the default context from the GjsContext is usually sensible. Add functions: gjs_runtime_push_context() gjs_runtime_pop_context() gjs_runtime_get_current_context() One potential concern here is the extensive use of GDataset to get data from a context, which involves locking overhead and hash table lookups and can be slow; since we can't use GJS with multiple JS_Runtimes in the same process due to the limitations of toggle references, perhaps we should enforce that and use global variables. https://bugzilla.gnome.org/show_bug.cgi?id=622896
* xulrunner 1.9.3: Fix assumption that jsid == jsvalColin Walters2010-09-301-3/+4
| | | | | | | | | | The two have always been conceptually distinct types. Even in 1.9.3, they are still the same in implementation, but to avoid a pile of warnings, we should avoid confusing them. Unfortunately, even the SpiderMonkey docs are wrong in a few places, so gjs' code confusing them is understandable. Anyways, fix up places that made this assumption.
* xulrunner 1.9.3: Use JS_AddValueRoot if availableColin Walters2010-09-301-18/+18
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=622896
* xulrunner 1.9.3: Consistently include compat.hColin Walters2010-09-301-0/+1
|
* dbus: Restore the previous behavior of returning undefinedJohan Bilien2010-09-171-1/+4
| | | | | | | | for methods with an empty out signature. I broke this with https://bugzilla.gnome.org/show_bug.cgi?id=629965 https://bugzilla.gnome.org/show_bug.cgi?id=629967
* Fix two prototype compilation warningsColin Walters2010-09-161-1/+1
|
* dbus: Replace the set_current_message with push/popJohan Bilien2010-05-041-15/+26
| | | | | | to avoid re-entrency issues. https://bugzilla.gnome.org/show_bug.cgi?id=617702
* add JS_BeginRequest/JS_EndRequest calls throughout the codebase.Havoc Pennington2010-05-011-0/+21
| | | | | | | This is one step toward thread safety. Remaining work includes at least: * put locks on our own global state * JS_SuspendRequest() when blocking in native code * JS_SetContextThread() on load and call contexts
* Delete some trailing whitespaceGJS_0_5Colin Walters2010-02-081-5/+5
|
* [dbus] Add getCurrentMessageContext, remove old _dbus_senderColin Walters2010-02-081-5/+88
| | | | | | | | | | | | | | | | | | The dbus binding had inconsistent and pretty broken support for retrieving the sender of a DBusMessage. The function gjs_js_add_dbus_props, when passed an object, added a _dbus_sender property. However, in many cases it won't be passed an object, such as a service method implementation. There are a number of cases here; the primary ones that we need to support are service methods, signals, and asynchronous callbacks. This patch regresses one case, which is that previously if you did a synchronous call that *also* returned multiple values, you could access _dbus_sender. This patch has no support for synchronous calls, however there is a workaround - convert them to asynchronous. https://bugzilla.gnome.org/show_bug.cgi?id=609121
* when dbus_connection_send_with_reply() fails, print connection and pending ↵Havoc Pennington2009-09-031-2/+4
| | | | | | | call status Otherwise the exception is a little bit opaque. Well, it is a little bit opaque anyway, but maybe this helps somewhat.
* Bug 585386: Add a flush() method to DBus bus object.C. Scott Ananian2009-06-111-0/+38
| | | | This can be used to ensure that DBus signals have been sent before continuing.
* Bug 584858: Move gjsdbus to gjs-dbus to match installed location.C. Scott Ananian2009-06-041-1/+1
| | | | | | | | In order for #include <gjs-dbus/dbus.h> in dbus-private.h to work both in the source tree and after it is installed in $INCUDEDIR/gjs-1.0/gjs-dbus, we need our locate copy of dbus.h to be in a directory named gjs-dbus, not gjsdbus.
* Bug 584858: Fix errors (and leftover debugging) from dbus merge.C. Scott Ananian2009-06-041-2/+0
| | | | | Commit e6466712a28c29f23e1e3e762c68ccc2d8e339a5 ported over some code contributed by Litl, but a few bugs crept in. This patch fixes them.
* Bug 580948 - Add DBus supportColin Walters2009-05-271-0/+1684
This patch merges in code from Litl implementing a DBus module. At a high level there are four pieces. First, the "gjs-dbus" library is a C support library for DBus. Second, the modules/dbus*.[ch] implement parts of the JavaScript API in C. Third, the modules/dbus.js file fills out the rest of the JavaScript API and implementation. Fourth, there are tests and examples.
View Lorry Controller Status