dbus issueshttps://gitlab.freedesktop.org/dbus/dbus/-/issues2023-05-27T07:19:05Zhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/12dbus-launch fails if user in too many groups OS X 10.52023-05-27T07:19:05ZBugzilla Migration Userdbus-launch fails if user in too many groups OS X 10.5## Submitted by Glen Whitney
Assigned to **D-Bus Maintainers**
**[Link to original bug (#19309)](https://bugs.freedesktop.org/show_bug.cgi?id=19309)**
## Description
Created attachment 21522
proposed patch to handle >17 groups on ...## Submitted by Glen Whitney
Assigned to **D-Bus Maintainers**
**[Link to original bug (#19309)](https://bugs.freedesktop.org/show_bug.cgi?id=19309)**
## Description
Created attachment 21522
proposed patch to handle >17 groups on Mac OS X 10.5
As of release 1.2.10, on Mac OS X 10.5, if a user attempting to execute
dbus_launch is in more than 17 groups, dbus-launch will always fail with the message:
Failed to get groups for user `<username>` primary GID `<gid>`: Unknown error 0
The cause to the problem appears to be the fact that under 10.5, getgrouplist() fails to update buf_count to the true number of groups when the buffer has too few slots to fit them all.
There is a detailed account of how this exact bug affected some GIMP users on gimper.net: http://gimper.net/viewtopic.php?f=18&t=3185&st=0&sk=t&sd=a&sid=a679a167e0a62ffbd984d06ac0be982f&start=0
Obviously a developer there ("skl") was able to work around the issue, but as far as I can tell s/he never posted the patches nor opened a DBus ticket. Since the bug also hit me (in getting Gnucash to work via macports) I thought I should open a ticket. I have attached the patch I used to correct the issue in my installation. The patch includes a long comment with further technical details.
Thanks for looking into whether this patch or a similar fix can be incorporated into a future release of DBus. Yours, Glen
**Patch 21522**, "proposed patch to handle >17 groups on Mac OS X 10.5":
[patch-dbus-sysdeps-unix.c.diff](/uploads/6cc42e81e9d026782c540cd7edb053ba/patch-dbus-sysdeps-unix.c.diff)
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/96dbus-launch: has non-obvious critical sections in which an X error would caus...2018-10-12T21:17:31ZBugzilla Migration Userdbus-launch: has non-obvious critical sections in which an X error would cause process leaks## Submitted by Роман Донченко
Assigned to **D-Bus Maintainers**
**[Link to original bug (#74698)](https://bugs.freedesktop.org/show_bug.cgi?id=74698)**
## Description
Created attachment 93633
Proposed patch
If an X error occurs ...## Submitted by Роман Донченко
Assigned to **D-Bus Maintainers**
**[Link to original bug (#74698)](https://bugs.freedesktop.org/show_bug.cgi?id=74698)**
## Description
Created attachment 93633
Proposed patch
If an X error occurs before the main dbus-launch process transmits the daemon's PID to the babysitter, x_io_error_handler will try to kill the bus with bus_pid_to_kill still set to -1. This will result in killing every process that dbus-launch can get its hands on.
I can easily reproduce this by running xvfb-run sh -c 'dbus-launch --autolaunch=11111111111111111111111111111111 &' a bunch of times.
The attached patch fixes this by making sure bus_pid_to_kill doesn't try to kill -1. It also fixes a related problem: if the X error happens after the fork but before the babysitter gets the bus PID, the bus won't be killed, because bus_pid_to_kill isn't initialized yet.
~~**Patch 93633**~~, "Proposed patch":
[dont-kill-minus-one.patch](/uploads/006e3b7320d4fb8bd62e213d319ae317/dont-kill-minus-one.patch)
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/90dbus-launch will refuse start a dbus-daemon though the previous started was t...2018-10-12T21:16:56ZBugzilla Migration Userdbus-launch will refuse start a dbus-daemon though the previous started was terminated## Submitted by Chengwei Yang `@chengwei`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#69877)](https://bugs.freedesktop.org/show_bug.cgi?id=69877)**
## Description
dbus-launch which used to start a dbus-daemon mainl...## Submitted by Chengwei Yang `@chengwei`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#69877)](https://bugs.freedesktop.org/show_bug.cgi?id=69877)**
## Description
dbus-launch which used to start a dbus-daemon mainly used in autolaunch:, in this situation, dbus-launch will save related infomations into X window system, for example, the bus daemon address. And will decide whether a dbus-daemon is already running according to if an address can get from X window system.
So here comes the problem: if the previously started dbus-daemon was terminated but the dbus-launch is still running, then the next connection request will always fail because dbus-launch refused to start a dbus-daemon.
This behaviour somehow like #bug25841, I'm not quite sure.
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/430_dbus_loop_iterate: Why isn't `timeout` defined as an integer data?2023-03-08T19:44:40ZXin Shi_dbus_loop_iterate: Why isn't `timeout` defined as an integer data?All places where `timeout` is used can be represented as an integer data type, and some places even require it, such as the _dbus_pollable_set_poll function.
https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/dbus/dbus-mainloop.c#L5...All places where `timeout` is used can be represented as an integer data type, and some places even require it, such as the _dbus_pollable_set_poll function.
https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/dbus/dbus-mainloop.c#L578
https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/dbus/dbus-mainloop.c#L663
https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/dbus/dbus-pollable-set.h#L106https://gitlab.freedesktop.org/dbus/dbus/-/issues/155DBus Manpage concerning SELinux wrong2018-10-15T13:47:43ZBugzilla Migration UserDBus Manpage concerning SELinux wrong## Submitted by Ralf Spenneberg
Assigned to **D-Bus Maintainers**
**[Link to original bug (#97528)](https://bugs.freedesktop.org/show_bug.cgi?id=97528)**
## Description
We have played around with dbus and SELinux. The only availab...## Submitted by Ralf Spenneberg
Assigned to **D-Bus Maintainers**
**[Link to original bug (#97528)](https://bugs.freedesktop.org/show_bug.cgi?id=97528)**
## Description
We have played around with dbus and SELinux. The only available documentation appears to be the dbus manpage. Unfortunately the example concerning the associate given in this manpage is not correct:
<associate own="org.freedesktop.Foobar" context="foo_t"/>
This should associate the ownership of the dbus service org.freedesktop.Foobar to the selinux domain foo_t. Actually you have to specify the full security context:
<associate own="org.freedesktop.Foobar" context="system_u:object_r:foo_t:s0"/>https://gitlab.freedesktop.org/dbus/dbus/-/issues/268dbus_message_iter_init returns false sometimes, and can then return true when...2019-05-18T11:50:16Zwoodhead99dbus_message_iter_init returns false sometimes, and can then return true when re-call it with the same dbus message?I am sorry if it is not a right place to post such issues.
dbus_message_iter_init returns false sometimes, and can return true when re-call it with the same dbus message.
The DBus message passed to the function is unmarshalled from a b...I am sorry if it is not a right place to post such issues.
dbus_message_iter_init returns false sometimes, and can return true when re-call it with the same dbus message.
The DBus message passed to the function is unmarshalled from a byte block over the TCP connection. It could return false one out of 5000 times. If I re-execute the function by jumping back with Gdb, it will return **true**. Is there something to notice when using DBus message related functions?
the DBus package is dbus-1.12.12-7.fc30.x86_64
The code is [here](https://github.com/zhiming99/rpc-frmwrk/blob/1b4bc4a5e1cf3b4f6a4888e42cf5d88b5e37dfde/combase/dmsgptr.cpp#L274).https://gitlab.freedesktop.org/dbus/dbus/-/issues/1D-BUS messages lost when auto-activating2023-05-27T07:19:04ZBugzilla Migration UserD-BUS messages lost when auto-activating## Submitted by Kimmo Hämäläinen
Assigned to **D-Bus Maintainers**
**[Link to original bug (#896)](https://bugs.freedesktop.org/show_bug.cgi?id=896)**
## Description
I made a simple D-BUS server which writes a line into a file whe...## Submitted by Kimmo Hämäläinen
Assigned to **D-Bus Maintainers**
**[Link to original bug (#896)](https://bugs.freedesktop.org/show_bug.cgi?id=896)**
## Description
I made a simple D-BUS server which writes a line into a file when it receives a
message and a client which sends 100 messages to the server with the
auto-activate flag up in every one of them. The server is not initially running
(it's supposed to be activated by the first message). The D-BUS system bus is
used and proper .service and .conf files are installed for the server.
When the client is run, one of the two things happen:
1) D-BUS system bus crashes (the server is not activated).
2) Another(!) D-BUS system bus appears to ps command's listing and the server is
activated, but the server does not receive any of the 100 messages.
In case of 2) happened and the client is run again, the server receives all the
100 messages (but there's still two D-BUS system buses running, according to ps).
Version: 1.5
### Blocking
* [Bug 52372](https://bugs.freedesktop.org/show_bug.cgi?id=52372)https://gitlab.freedesktop.org/dbus/dbus/-/issues/461DBus method param issue2023-06-05T15:36:09Z杨奎DBus method param issueI want call a dbus method of signature was a(ss).I used the following code to construct the "a (ss)" parameter, but it did not pass. The console output is as follows:
> Array or variant type requires that type begin_struct be written, b...I want call a dbus method of signature was a(ss).I used the following code to construct the "a (ss)" parameter, but it did not pass. The console output is as follows:
> Array or variant type requires that type begin_struct be written, but string was written. The overall signature expected here was 'a(ss)' and we are on byte 1 of that signature.
This is my implementation code:
```c
DBusMessageIter iter;
DBusMessageIter subIter;
dbus_message_iter_init_append(msg, &iter);
if (!dbus_message_iter_open_container(&iter, DBUS_TYPE_ARRAY,
"(ss)",
&subIter)) {
fprintf(stderr, "%s", "iter init fail\n");
exit(1);
}
String a = "aaaaaa";
String b = "bbbbbb";
dbus_message_iter_append_basic(&subIter, DBUS_TYPE_STRING, &a);
dbus_message_iter_append_basic(&subIter, DBUS_TYPE_STRING, &b);
// dbus_message_iter_append_basic(&subIter, DBUS_TYPE_STRING, &c);
// dbus_message_iter_append_basic(&subIter, DBUS_TYPE_STRING, &d);
dbus_message_iter_close_container(&iter, &subIter);
```https://gitlab.freedesktop.org/dbus/dbus/-/issues/428dbus-monitor: Add an option to break the loop on first match2022-12-09T13:18:33ZKBardbus-monitor: Add an option to break the loop on first match## Is your feature request related to a problem? Please describe.
Currently, `dbus-monitor` isn't exactly script-friendly. It is interesting to watch what's going on interactively and then interrupt it when we're done. However, from wit...## Is your feature request related to a problem? Please describe.
Currently, `dbus-monitor` isn't exactly script-friendly. It is interesting to watch what's going on interactively and then interrupt it when we're done. However, from within scripts, we usually don't want to keep monitoring forever but exit when certain conditions are met.
## Describe the solution you'd like
An extra option akin to `--chgexit` of `watch` (with a better name) would be very convenient to have. It should break the `dbus_connection_read_write_dispatch()` loop as soon as the first match arrives and return 0.
## Describe alternatives you've considered
One way around in shell scripts is to pipe the output to a `while` loop and do something like this:
```sh
dbus-monitor ... \
| while read -r line
do case $line in
*PropertiesChanged) break;;
*) continue
esac
done
```
It's obviously not ideal, as a second call to `write()` is needed in order to trigger `SIGPIPE`, else it hangs indefinitely. With GNU `grep -m 1`, it's possible to stop processing after the first match but it's the same story here as well, not to mention it's not portable. `pkill dbus-monitor` and the likes work, though, because they close the write end and cause `read()` to encounter `EOF`, thus the whole pipeline is closed immediately.
## Additional context
On entrance, the following two signals are always listed:
```
#type timestamp serial sender destination path interface member
# in_reply_to
sig 1670589765.544835 2 org.freedesktop.DBus :1.720 /org/freedesktop/DBus org.freedesktop.DBus NameAcquired
sig 1670589765.544993 4 org.freedesktop.DBus :1.720 /org/freedesktop/DBus org.freedesktop.DBus NameLost
```
They should be ignored so as to not end the loop prematurely.https://gitlab.freedesktop.org/dbus/dbus/-/issues/301dbus-monitor gets disconnected by dbus-broker for trying to send a message2022-10-11T11:45:12ZWill Thompsondbus-monitor gets disconnected by dbus-broker for trying to send a messageWhile smoke-testing Bustle on a Fedora 32 computer I noticed that `dbus-monitor` sometimes gets abruptly disconnected from the bus. I found the following in the journal:
```
May 20 23:26:09 gelf dbus-broker[2628]: Monitor :1.311 is bein...While smoke-testing Bustle on a Fedora 32 computer I noticed that `dbus-monitor` sometimes gets abruptly disconnected from the bus. I found the following in the journal:
```
May 20 23:26:09 gelf dbus-broker[2628]: Monitor :1.311 is being disconnected as it attempted to send a message.
```
Sure enough, strace confirms that it's trying to send a message:
```
$ strace -e write=3 dbus-monitor --pcap >ohno.pcap
...
sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\2\1\1\0\0\0\0\3\0\0\0\30\0\0\0\6\1s\0\6\0\0\0:1.322\0\0"..., iov_len=40}, {iov_base="", iov_len=0}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 40
* 40 bytes in buffer 0
| 00000 6c 02 01 01 00 00 00 00 03 00 00 00 18 00 00 00 l............... |
| 00010 06 01 73 00 06 00 00 00 3a 31 2e 33 32 32 00 00 ..s.....:1.322.. |
| 00020 05 01 75 00 12 00 00 00 ..u..... |
```
Deserializing this with `GDBusMessage` gives:
```
Type: method-return
Flags: no-reply-expected
Version: 0
Serial: 3
Headers:
reply-serial -> uint32 18
destination -> ':1.322'
Body: ()
UNIX File Descriptors:
(none)
```
Rather suspiciously, the last few messages in the pcap file are:
1. AddMatch from :1.322 to org.freedesktop.DBus, serial 17
2. org.freedesktop.DBus responding to that method call
3. org.freedesktop.DBus responding to the invisible call with serial 18
4. org.freedesktop.DBus.Local.Disconnected
That's as far as I got. :(https://gitlab.freedesktop.org/dbus/dbus/-/issues/161dbus-monitor: optionally print monotonic timestamps in Linux kernel style2018-10-15T13:45:03ZBugzilla Migration Userdbus-monitor: optionally print monotonic timestamps in Linux kernel style## Submitted by Mikhail Durnev
Assigned to **D-Bus Maintainers**
**[Link to original bug (#98898)](https://bugs.freedesktop.org/show_bug.cgi?id=98898)**
## Description
Created attachment 128263
Add timestamps to dbus-monitor logs
...## Submitted by Mikhail Durnev
Assigned to **D-Bus Maintainers**
**[Link to original bug (#98898)](https://bugs.freedesktop.org/show_bug.cgi?id=98898)**
## Description
Created attachment 128263
Add timestamps to dbus-monitor logs
Dbus logs from IVI (In-Vehicle Infotainment) are difficult or impossible to fully analyse because they do not have timestamps.
**Patch 128263**, "Add timestamps to dbus-monitor logs":
[add-timestamps-to-dbus-monitor-logs.patch](/uploads/385e2a020b1bc738f7c900b091c9961c/add-timestamps-to-dbus-monitor-logs.patch)https://gitlab.freedesktop.org/dbus/dbus/-/issues/10dbus-monitor output could be better worded2023-05-27T07:19:05ZBugzilla Migration Userdbus-monitor output could be better worded## Submitted by gsr.bugs
Assigned to **Havoc Pennington**
**[Link to original bug (#18459)](https://bugs.freedesktop.org/show_bug.cgi?id=18459)**
## Description
dbus-monitor reports things in a very verbose way, but then seems to ...## Submitted by gsr.bugs
Assigned to **Havoc Pennington**
**[Link to original bug (#18459)](https://bugs.freedesktop.org/show_bug.cgi?id=18459)**
## Description
dbus-monitor reports things in a very verbose way, but then seems to save some letters for no reason, saying "dest=" instead of "destination=".
It would be nice if the output would be fully worded, so its output could be better feed back into it (scripts, copy&paste, etc) or any other tool or even just to show and reinforce the proper syntax.
Thanks.https://gitlab.freedesktop.org/dbus/dbus/-/issues/18Dbus needs better tracking (logging) possibilities2023-01-26T16:00:04ZBugzilla Migration UserDbus needs better tracking (logging) possibilities## Submitted by Dag Nygren
Assigned to **D-Bus Maintainers**
**[Link to original bug (#23375)](https://bugs.freedesktop.org/show_bug.cgi?id=23375)**
## Description
I have been trying to debug a dbus configuration problem here for ...## Submitted by Dag Nygren
Assigned to **D-Bus Maintainers**
**[Link to original bug (#23375)](https://bugs.freedesktop.org/show_bug.cgi?id=23375)**
## Description
I have been trying to debug a dbus configuration problem here for ages now and noticed that the possibilities of tracking a message through DBUS are virtually non-existant. With the new Polcykit etc. coming up it would be a lot easier if we got:
1. All debugging info to syslog. Now if you turn on verbose for the system bus daemon it doesn't write to stderr, but somewhere, and you have no possibility to catch it.
2. Tracking of all the config files (paths) opened to syslog
3. Tracking of messages passed through. Incoming info, security decisions and where it was sent.
I am sure there could be more, but the above would have saved me some days of trying to figure out...
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/313dbus or libdbus appears to close the connection when stdin from a console (/d...2020-11-02T20:35:51ZJohn Baublitzdbus or libdbus appears to close the connection when stdin from a console (/dev/tty*) is sent as an argumentI bumped into an interesting issue where sending stdin from a process with a pseudoterminal as the controlling terminal works properly, but when run from a console, the following error is encountered: https://github.com/stratis-storage/p...I bumped into an interesting issue where sending stdin from a process with a pseudoterminal as the controlling terminal works properly, but when run from a console, the following error is encountered: https://github.com/stratis-storage/project/issues/233.
The specific error of note here is `org.freedesktop.DBus.Error.Disconnected`. We have an alternate IPC mechanism that uses Unix sockets to transfer the file descriptor so I tried sending stdin from the console to the daemon process and that worked. This rules out that this is a limitation of Unix sockets. I also wondered if this had to do with the Python libraries that we use on top of python-dbus in our Python CLI. I wanted to rule that out so I wrote a D-Bus client in Rust to invoke just the problematic D-Bus method call:
```
use std::{error::Error, io::stdin, os::unix::io::AsRawFd, time::Duration};
use dbus::{arg::OwnedFd, blocking::Connection};
fn main() -> Result<(), Box<dyn Error>> {
let key_desc = std::env::args()
.nth(1)
.ok_or_else(|| "Key description is a required argument")?;
let connection = Connection::new_system()?;
let proxy = connection.with_proxy(
"org.storage.stratis2",
"/org/storage/stratis2",
Duration::from_secs(5),
);
println!("Enter key data:");
let ((changed, _), rc, rs): ((bool, bool), u16, String) = proxy.method_call(
"org.storage.stratis2.Manager.r2",
"SetKey",
(key_desc, unsafe { OwnedFd::new(stdin().as_raw_fd()) }, true),
)?;
if rc != 0 {
Err(format!("Failed with error code {}: {}", rc, rs))?
} else if !changed {
Err("The requested action had no effect")?
} else {
Ok(())
}
}
```
This also worked from a pseudoterminal-controlled shell, and failed with the same error when run from the console. This leads me to believe that this is a bug in either dbus itself or libdbus as both the Rust library (dbus-rs) and python-dbus bind to libdbus.
One additional piece of information that might be useful is that I monitored the D-Bus while this was occuring and no call to our `SetKey` method is ever registered in `dbus-monitor` indicating that it is never actually sent across the D-Bus before the connection is closed. strace also seems to indicate that the `sendmsg` call that is supposed to send the `SetKey` message succeeds according to the return value, but immediately after that, the `recvmsg` call appears to get a `SIGHUP` and returns 0 bytes read. The file descriptor for the D-Bus connection is then closed.
Let me know if you need any more information.https://gitlab.freedesktop.org/dbus/dbus/-/issues/16dbus-send can't send dict args2023-05-27T07:19:05ZBugzilla Migration Userdbus-send can't send dict args## Submitted by Tomas Pelka
Assigned to **D-Bus Maintainers**
**[Link to original bug (#19807)](https://bugs.freedesktop.org/show_bug.cgi?id=19807)**
## Description
Description of problem:
Dbus-send unable to send dict arguments.
...## Submitted by Tomas Pelka
Assigned to **D-Bus Maintainers**
**[Link to original bug (#19807)](https://bugs.freedesktop.org/show_bug.cgi?id=19807)**
## Description
Description of problem:
Dbus-send unable to send dict arguments.
Version-Release number of selected component (if applicable):
dbus-1.1.2
How reproducible:
100%
Steps to Reproduce:
1. Send:
dbus-send --print-reply --dest=org.freedesktop.DBus --type=signal \
/org/freedesktop/DBus/Examples/Echo org.freedesktop.DBus.Hello \ dict:string:int32:"one",1,"two",2,"three",3
Expected results:
Message should be send without error.
Actual result:
process 13920: arguments to dbus_message_iter_open_container() were incorrect, assertion "(type == DBUS_TYPE_STRUCT && contained_signature == NULL) || (type == DBUS_TYPE_DICT_ENTRY && contained_signature == NULL) || (type == DBUS_TYPE_VARIANT && contained_signature != NULL) || (type == DBUS_TYPE_ARRAY && contained_signature != NULL)" failed in file dbus-message.c line 2356.
This is normally a bug in some application using the D-Bus library.
process 13920: dbus message iterator looks uninitialized or corrupted
process 13920: arguments to dbus_message_iter_append_basic() were incorrect, assertion "_dbus_message_iter_append_check (real)" failed in file dbus-message.c line 2239.
This is normally a bug in some application using the D-Bus library.
process 13920: dbus message iterator looks uninitialized or corrupted
process 13920: arguments to dbus_message_iter_append_basic() were incorrect, assertion "_dbus_message_iter_append_check (real)" failed in file dbus-message.c line 2239.
This is normally a bug in some application using the D-Bus library.
process 13920: dbus message iterator looks uninitialized or corrupted
process 13920: arguments to dbus_message_iter_close_container() were incorrect, assertion "_dbus_message_iter_append_check (real_sub)" failed in file dbus-message.c line 2414.
This is normally a bug in some application using the D-Bus library.
process 13920: arguments to dbus_message_iter_open_container() were incorrect, assertion "(type == DBUS_TYPE_STRUCT && contained_signature == NULL) || (type == DBUS_TYPE_DICT_ENTRY && contained_signature == NULL) || (type == DBUS_TYPE_VARIANT && contained_signature != NULL) || (type == DBUS_TYPE_ARRAY && contained_signature != NULL)" failed in file dbus-message.c line 2356.
This is normally a bug in some application using the D-Bus library.
process 13920: dbus message iterator looks uninitialized or corrupted
process 13920: arguments to dbus_message_iter_append_basic() were incorrect, assertion "_dbus_message_iter_append_check (real)" failed in file dbus-message.c line 2239.
This is normally a bug in some application using the D-Bus library.
process 13920: dbus message iterator looks uninitialized or corrupted
process 13920: arguments to dbus_message_iter_append_basic() were incorrect, assertion "_dbus_message_iter_append_check (real)" failed in file dbus-message.c line 2239.
This is normally a bug in some application using the D-Bus library.
process 13920: dbus message iterator looks uninitialized or corrupted
process 13920: arguments to dbus_message_iter_close_container() were incorrect, assertion "_dbus_message_iter_append_check (real_sub)" failed in file dbus-message.c line 2414.
This is normally a bug in some application using the D-Bus library.
process 13920: arguments to dbus_message_iter_open_container() were incorrect, assertion "(type == DBUS_TYPE_STRUCT && contained_signature == NULL) || (type == DBUS_TYPE_DICT_ENTRY && contained_signature == NULL) || (type == DBUS_TYPE_VARIANT && contained_signature != NULL) || (type == DBUS_TYPE_ARRAY && contained_signature != NULL)" failed in file dbus-message.c line 2356.
This is normally a bug in some application using the D-Bus library.
process 13920: dbus message iterator looks uninitialized or corrupted
process 13920: arguments to dbus_message_iter_append_basic() were incorrect, assertion "_dbus_message_iter_append_check (real)" failed in file dbus-message.c line 2239.
This is normally a bug in some application using the D-Bus library.
process 13920: dbus message iterator looks uninitialized or corrupted
process 13920: arguments to dbus_message_iter_append_basic() were incorrect, assertion "_dbus_message_iter_append_check (real)" failed in file dbus-message.c line 2239.
This is normally a bug in some application using the D-Bus library.
process 13920: dbus message iterator looks uninitialized or corrupted
process 13920: arguments to dbus_message_iter_close_container() were incorrect, assertion "_dbus_message_iter_append_check (real_sub)" failed in file dbus-message.c line 2414.
This is normally a bug in some application using the D-Bus library.
Error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/338dbus-send core dump on line-feed2021-07-19T12:27:17Zsimeonfelisdbus-send core dump on line-feedI'm on some embedded platform and encountered a core dump of dbus-send by accidently pasting a line feed in the INTERFACE.MEMBER argument:
```
dbus-send --system --type=method_call --print-reply --dest=com.example.service /com/example/s...I'm on some embedded platform and encountered a core dump of dbus-send by accidently pasting a line feed in the INTERFACE.MEMBER argument:
```
dbus-send --system --type=method_call --print-reply --dest=com.example.service /com/example/service/api com.example.service.api.call"
"
[ 1182.630740] core dump of dbus-send (PID=3101) (SIG=6) saved at
```
And this is all, no core dump on this system.
```
dbus-daemon --version
D-Bus Message Bus Daemon 1.8.20
```
Maybe related to #283 or #227https://gitlab.freedesktop.org/dbus/dbus/-/issues/452dbus-send manual page does not document return value.2023-03-15T19:05:59ZBram Stolkdbus-send manual page does not document return value.It appears that dbus-send will return 0 on success and 1 on failure.
However, this is not documented in the manual page for dbus-send.
Tested on:
OS: Ubuntu 22.10
Version: 1.14.0-2ubuntu3
To reproduce:
$ man dbus-sendIt appears that dbus-send will return 0 on success and 1 on failure.
However, this is not documented in the manual page for dbus-send.
Tested on:
OS: Ubuntu 22.10
Version: 1.14.0-2ubuntu3
To reproduce:
$ man dbus-sendhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/474DBUS_SESSION_BUS_ADDRESS not set when using su or sudo2023-08-24T19:32:01ZAdam ClaterDBUS_SESSION_BUS_ADDRESS not set when using su or sudo## To reproduce
Steps to reproduce the behavior:
1. su to user
2. run: systemctl --user daemon-reload
3. Error: Failed to connect to bus: No medium found
## Expected result
systemctl--user daemon-reload should reload the users unit fil...## To reproduce
Steps to reproduce the behavior:
1. su to user
2. run: systemctl --user daemon-reload
3. Error: Failed to connect to bus: No medium found
## Expected result
systemctl--user daemon-reload should reload the users unit files
## Actual result
When a user ssh's into the host, the DBUS_SESSION_BUS_ADDRESS environment variable is set to ```unix:path=/run/user/`id -u`/bus```, when you use su or sudo, this variable is not set, resulting in systemctl --user not working.
## Additional context
Add any other context about the problem here.https://gitlab.freedesktop.org/dbus/dbus/-/issues/402DBus Spawn ChildExited Error2022-07-13T09:05:53ZMohit VermaDBus Spawn ChildExited ErrorHi, I am currently doing some work with the Gnome-Control-Center printing panel ans CupsPkHelper .The G-C-C does a gdbus_connection_call to cups-pk-helper for discovery of printer devices. This discovery method is currently being replace...Hi, I am currently doing some work with the Gnome-Control-Center printing panel ans CupsPkHelper .The G-C-C does a gdbus_connection_call to cups-pk-helper for discovery of printer devices. This discovery method is currently being replaced with PAPPL & some other API calls.
The problem is that as soon as I add PAPPL API calls for this, the G-C-C throws an error `(gnome-control-center:11427): printers-cc-panel-WARNING **: 13:39:39.747: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 127` .
I have tried looking up for a solution but couldn't find anything useful.https://gitlab.freedesktop.org/dbus/dbus/-/issues/40dbus-specification (or an appendix) should document the well-known errors2018-10-12T21:08:30ZBugzilla Migration Userdbus-specification (or an appendix) should document the well-known errors## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#34528)](https://bugs.freedesktop.org/show_bug.cgi?id=34528)**
## Description
I was about to ask Lennart to document the new errors from Bug...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#34528)](https://bugs.freedesktop.org/show_bug.cgi?id=34528)**
## Description
I was about to ask Lennart to document the new errors from Bug #34527 in dbus-specification when I realised no other errors were documented either, except a few that are mentioned in passing in descriptions of bus methods.
We should have some binding-neutral list of all the well-known errors in the o.fd.DBus.Error namespace (the nearest we currently have is the combination of dbus-protocol.h, and its equivalents in reimplementations like GDBus.)
Version: 1.5