dbus issueshttps://gitlab.freedesktop.org/dbus/dbus/-/issues2023-12-01T21:45:20Zhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/488CI failure in opensuse mingw64 cmake debug, possibly related to: Failed to de...2023-12-01T21:45:20ZSimon McVittieCI failure in opensuse mingw64 cmake debug, possibly related to: Failed to determine console output code pageJob [#52256626](https://gitlab.freedesktop.org/dbus/dbus/-/jobs/52256626) failed for c807028db49ed418bf1c34b2c9469d46f4023a4a. All the GLib-based tests seem to be failing for `opensuse mingw64 cmake debug`.
They emit this warning, which...Job [#52256626](https://gitlab.freedesktop.org/dbus/dbus/-/jobs/52256626) failed for c807028db49ed418bf1c34b2c9469d46f4023a4a. All the GLib-based tests seem to be failing for `opensuse mingw64 cmake debug`.
They emit this warning, which might be related:
```
15: GLib-WARNING (recursed) **: Failed to determine console output code page: Invalid access.. Falling back to UTF-8
```
`debian mingw32 meson` is running at least a subset of these tests (at least `corrupt` gets run) and does not have the same problem. This might be because it's using a different GLib version, or maybe it has different environment variables or something?
What GLib is trying to do here is:
```
locale = g_getenv ("LANG");
if (locale != NULL && locale[0] != '\0')
...
/* next try querying console codepage using native win32 API */
if (raw == NULL)
{
cp = GetConsoleOutputCP ();
if (cp)
{
sprintf (buf, "CP%u", cp);
raw = buf;
}
else if (GetLastError () != ERROR_INVALID_HANDLE)
{
gchar *emsg = g_win32_error_message (GetLastError ());
g_warning ("Failed to determine console output code page: %s. "
"Falling back to UTF-8", emsg);
g_free (emsg);
}
}
```
so maybe we can work around this with `export LANG=C.UTF-8` or `export LC_ALL=C.UTF-8` or something similar.https://gitlab.freedesktop.org/dbus/dbus/-/issues/456Native Windows CI not being run2023-05-16T11:01:28ZSimon McVittieNative Windows CI not being runhttps://gitlab.freedesktop.org/dbus/dbus/-/jobs/41624837 took at least 70 minutes, and I wanted to get *some* amount of CI to work today, so I disabled the native Windows CI jobs for now.
We should re-enable the Windows CI if/when it wo...https://gitlab.freedesktop.org/dbus/dbus/-/jobs/41624837 took at least 70 minutes, and I wanted to get *some* amount of CI to work today, so I disabled the native Windows CI jobs for now.
We should re-enable the Windows CI if/when it works reliably, but I've run out of time to get that working.https://gitlab.freedesktop.org/dbus/dbus/-/issues/404Increase minimum version of MSVC to one that we test in CI2022-07-20T13:27:46ZSimon McVittieIncrease minimum version of MSVC to one that we test in CIWe have a lot of things in our build that are being held back by "but what if MSVC doesn't support it?":
* making C99 `va_copy` a hard requirement (this would let us drop the probes for whether we need `__va_copy()` or an open-coded imp...We have a lot of things in our build that are being held back by "but what if MSVC doesn't support it?":
* making C99 `va_copy` a hard requirement (this would let us drop the probes for whether we need `__va_copy()` or an open-coded implementation for MSVC)
* making C99 `static inline` a hard requirement (this would let us drop the `__inline` fallback)
* making C99 `snprintf()` a hard requirement (this would let us drop the `_snprintf` fallback in CMake)
* making C99 `strtoll()` and `strtoull()` a hard requirement (this would let us drop `tools/strto*ll.c` and related fallbacks)
* making a C99-compatible `<stdint.h>` a hard requirement (we can't necessarily redefine `dbus_int32_t` etc. for API reasons as discussed on !283, but we could at least add static assertions that say they are interchangeable, and potentially start using them internally)
MSVC 2013+ support quite a large subset of C99, and MSVC 2015+ have a much larger subset.
Now that @elmarco has added a CI job that runs on MSVC 2015, I'd like to start documenting that we require a C99 compiler for Unix, or at least the subset of C99 supported by MSVC 2015 for Windows. This would let us drop a lot of these workarounds, many of which we have trouble actually testing in practice (which probably means a lot of them are already broken and we just don't know it).
Alternatively, if there are reasons why we need to continue to support an older version of MSVC (like 2013?), then we should have CI that routinely tests that version, to verify that we haven't regressed.
Prior art: GLib is in the same situation as dbus (it's written in C, and wants to be portable to most Unixes, plus Windows and macOS), and the GLib developers publish a set of [toolchain requirements](https://gitlab.gnome.org/GNOME/glib/-/blob/main/docs/toolchain-requirements.md).https://gitlab.freedesktop.org/dbus/dbus/-/issues/369Windows implementation of _dbus_platform_rmutex_lock() does not match the exp...2022-05-05T14:20:41ZRalf HabackerWindows implementation of _dbus_platform_rmutex_lock() does not match the expectations of the client codeThe unix variant of _dbus_platform_rmutex_lock() is implemented as
```
void
_dbus_platform_rmutex_lock (DBusRMutex *mutex)
{
PTHREAD_CHECK ("pthread_mutex_lock", pthread_mutex_lock (&mutex->lock));
}
```
It asserts in any error case a...The unix variant of _dbus_platform_rmutex_lock() is implemented as
```
void
_dbus_platform_rmutex_lock (DBusRMutex *mutex)
{
PTHREAD_CHECK ("pthread_mutex_lock", pthread_mutex_lock (&mutex->lock));
}
```
It asserts in any error case and let client code simple use
```
_dbus_platform_rmutex_lock (mutex)
/* protected access */
_dbus_platform_rmutex_unlock (mutex)
```
This behavior is not not implemented in the Windows code:
```
void
_dbus_platform_rmutex_lock (DBusRMutex *mutex)
{
WaitForSingleObject ((HANDLE *) mutex, INFINITE);
}
```
which can lead to threading problems, such as those reported at https://gitlab.freedesktop.org/dbus/dbus/-/issues/368.https://gitlab.freedesktop.org/dbus/dbus/-/issues/368Invalid uses of _dbus_global_lock() in windows related code2022-05-17T23:24:29ZRalf HabackerInvalid uses of _dbus_global_lock() in windows related codeIn the Windows-related dbus source code, there are several calls to _dbus_global_lock() in the form
```
mutex = _dbus_global_lock (cDBusAutolaunchMutex);
...
_dbus_global_unlock (&mutex);
```
which will fail due to the implementat...In the Windows-related dbus source code, there are several calls to _dbus_global_lock() in the form
```
mutex = _dbus_global_lock (cDBusAutolaunchMutex);
...
_dbus_global_unlock (&mutex);
```
which will fail due to the implementation of the listed function if access to the returned mutex fails.https://gitlab.freedesktop.org/dbus/dbus/-/issues/360activation-service-reload in test-bus still fails with memory leaks on Windows2021-12-10T07:56:58ZRalf Habackeractivation-service-reload in test-bus still fails with memory leaks on WindowsRunning test-bus from a gcc cmake build for Windows from recent master with
```
set DBUS_TEST_TIMEOUT_MULTIPLIER=2
ctest -R test-bus$ --output-on-failure --timeout 180
```
fails on a local machine with the following error:
```
9: ok 8...Running test-bus from a gcc cmake build for Windows from recent master with
```
set DBUS_TEST_TIMEOUT_MULTIPLIER=2
ctest -R test-bus$ --output-on-failure --timeout 180
```
fails on a local machine with the following error:
```
9: ok 8 - activation-service-reload
9: # activation-service-reload test took 3 seconds
9: not ok 9 - activation-service-reload leaked 18 blocks
9: # Running test: unix-fds-passing
9: ok 10 # SKIP fd-passing not supported on this platform
9: ok 11 - unix-fds-passing
9: # unix-fds-passing test took 0 seconds
9: not ok 12 - unix-fds-passing leaked 18 blocks
9: # 2/12 tests failed
9: 1..12
1/1 Test #9: test-bus .........................***Failed 8.09 sec
```
The error happens regardless if running on a native host or with the help of wine.
The whole log file generated by this test has been appended [error.log](/uploads/0d25ec2ff46ee472664e93bad70ebd19/error.log)https://gitlab.freedesktop.org/dbus/dbus/-/issues/357test-spawn-oom fails on Windows with memory checking enabled2021-12-06T13:02:32ZRalf Habackertest-spawn-oom fails on Windows with memory checking enabledRunning test-spawn-oom with memory checking enabled on Windows fails with the following errors:
```
dbus[32]: error: Not expecting error when launching segfaulting executable: org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to spawn ...Running test-spawn-oom with memory checking enabled on Windows fails with the following errors:
```
dbus[32]: error: Not expecting error when launching segfaulting executable: org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to spawn child
```
How to reproduce
----------------
In dbus/dbus-memory.c change the mentioned location below, then compile and run test-spawn-oom
```
dbus_bool_t
_dbus_decrement_fail_alloc_counter (void)
{
_dbus_initialize_malloc_debug ();
-#ifdef DBUS_WIN
+#ifdef _DBUS_WIN
```
Additional information
----------------------
With !223 the new error name has been introduced and needs to be added to this test as expected error.https://gitlab.freedesktop.org/dbus/dbus/-/issues/355build error: cast between incompatible function types from 'FARPROC'2021-11-30T09:31:50ZRalf Habackerbuild error: cast between incompatible function types from 'FARPROC'While trying to reproduce the issue reported at #353 with a local docker build with autotools, it fails with
```
../../dbus/dbus-sysdeps-win.c: In function 'load_ex_ip_helper_procedures':
../../dbus/dbus-sysdeps-win.c:129:43: error: cast...While trying to reproduce the issue reported at #353 with a local docker build with autotools, it fails with
```
../../dbus/dbus-sysdeps-win.c: In function 'load_ex_ip_helper_procedures':
../../dbus/dbus-sysdeps-win.c:129:43: error: cast between incompatible function types from 'FARPROC' {aka 'long long int (*)()'} to 'DWORD (*)(struct _MIB_TCPTABLE_OWNER_PID **, BOOL, void *, DWORD, DWORD)' {aka 'long unsigned int (*)(struct _MIB_TCPTABLE_OWNER_PID **, int, void *, long unsigned int, long unsigned int)'} [-Werror=cast-function-type]
lpfnAllocateAndGetTcpExTableFromStack = (ProcAllocateAndGetTcpExtTableFromStack)GetProcAddress (hModule, "AllocateAndGetTcpExTableFromStack");
^
```
I wonder why this does not occur on gitlab CI, since it uses the same docker image and packages.
The build steps performed, which are the same as those performed on Gitlab CI, are:
```
sudo docker pull debian:buster-slim
sudo docker run -v $PWD:/mnt -it debian:buster-slim /bin/bash
cd mnt
ci_buildsys=autotools ci_distro=debian ci_docker= ci_in_docker=yes ci_host=x86_64-w64-mingw32 ci_local_packages=yes ci_suite=buster ci_variant=debug ./tools/ci-install.sh
ci_buildsys=autotools ci_distro=debian ci_docker= ci_host=x86_64-w64-mingw32 ci_local_packages=yes ci_parallel=2 ci_suite=buster ci_test=yes ci_test_fatal=yes ci_variant=debug ci_runtime=static ./tools/ci-build.sh
```https://gitlab.freedesktop.org/dbus/dbus/-/issues/354If dbus-daemon fails to start up, Windows dbus-run-session does not detect it2021-11-25T15:55:43ZSimon McVittieIf dbus-daemon fails to start up, Windows dbus-run-session does not detect it## Steps to reproduce
Seen in for example https://gitlab.freedesktop.org/rhabacker/dbus/-/jobs/16153796 due to #353. Could be replicated by altering the dbus-daemon to `exit(1)` during startup (before the `--ready-event-handle` is signa...## Steps to reproduce
Seen in for example https://gitlab.freedesktop.org/rhabacker/dbus/-/jobs/16153796 due to #353. Could be replicated by altering the dbus-daemon to `exit(1)` during startup (before the `--ready-event-handle` is signalled), or by replacing it with an older dbus-daemon that does not implement the `--ready-event-handle` option.
## Expected result
If the dbus-daemon fails before the `--ready-event-handle` is signalled, then `dbus-run-session` should detect that, and exit unsuccessfully.
## Actual result
`dbus-run-session` does not exit until the 30 second timeout for `_dbus_win_event_wait()` has elapsed.https://gitlab.freedesktop.org/dbus/dbus/-/issues/353x86_64-w64-mingw32-cmake-debug CI sometimes fails with 'Library libexpat-1.dl...2021-12-01T12:17:24ZRalf Habackerx86_64-w64-mingw32-cmake-debug CI sometimes fails with 'Library libexpat-1.dll (..) not found'https://gitlab.freedesktop.org/rhabacker/dbus/-/jobs/16153796
> 29: 002b:err:module:import_dll Library libexpat-1.dll (which is needed by L"z:\\builds\\rhabacker\\dbus\\ci-build-debug-x86_64-w64-mingw32\\bin\\dbus-daemon.exe") not foundhttps://gitlab.freedesktop.org/rhabacker/dbus/-/jobs/16153796
> 29: 002b:err:module:import_dll Library libexpat-1.dll (which is needed by L"z:\\builds\\rhabacker\\dbus\\ci-build-debug-x86_64-w64-mingw32\\bin\\dbus-daemon.exe") not foundhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/297CI error: Failed to start message bus: Failed to open "z:/builds/xxx/dbus/ci-...2021-11-23T14:04:23ZRalf HabackerCI error: Failed to start message bus: Failed to open "z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/share\dbus-1\session.conf": Path not found.With !185 on running test cases the following error is visible:
```
28: Test command: /usr/bin/wine "z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/bin/dbus-run-session.exe" "--config-file=z:/builds/xxx/dbus/ci-build-production...With !185 on running test cases the following error is visible:
```
28: Test command: /usr/bin/wine "z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/bin/dbus-run-session.exe" "--config-file=z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/test/data/valid-config-files/tmp-session.conf" "--dbus-daemon=z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/bin/dbus-daemon.exe" "z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/bin/test-ids.exe" "--tap"
28: Environment variables:
28: DBUS_SESSION_BUS_PID=
28: DBUS_SESSION_BUS_ADDRESS=
28: DBUS_FATAL_WARNINGS=1
28: DBUS_TEST_DAEMON=z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/bin/dbus-daemon.exe
28: DBUS_TEST_DATA=z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/test/data
28: DBUS_TEST_HOMEDIR=z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/dbus
28: Test timeout computed to be: 180
28: dbus[45]: error: Failed to start message bus: Failed to open "z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/share\dbus-1\session.conf": Path not found.
28: Backtrace:
28: 0 0xf7f24067
28: 1 0x7bc8191e in ntdll
28: 2 0x7bc88b45 in ntdll
28: 3 0x7bc8b05f in ntdll
28: 4 0x7b47832a in kernel32
28: 5 0x7b4784b3 in kernel32
28: 6 0x7b47851d in kernel32
28: 7 dump_backtrace+0xa6 [../../dbus/dbus-sysdeps-win.c:2790] in libdbus-1-3
28: 8 _dbus_print_backtrace+0xb [../../dbus/dbus-sysdeps-win.c:2801] in libdbus-1-3
28: 9 _dbus_abort+0xc [../../dbus/dbus-sysdeps.c:93] in libdbus-1-3
28: 10 _dbus_warn+0x6e [../../dbus/dbus-internals.c:259] in libdbus-1-3
28: 11 main+0xa97 [../../bus/main.c:705] in dbus-daemon
28: 12 EntryPoint+0xffffffffffffffff in dbus-daemon
28: 13 0x7b463e32 in kernel32
28: 14 0x7b4661ac in kernel32
28: 15 0x7b463e3e in kernel32
28: ok 1 - connected to session bus
28: ok 2 - session bus server ID is cabccb0f4fd7772af17928e35eb578c0
28: ok 3 - session bus server ID length is 32
28: ok 4 - session bus ID is 8d96dbfeb2abc176b6ce3b595eb578c0
28: ok 5 - session bus ID length is 32
28: 1..5
28/29 Test #28: test-ids ......................... Passed 1.72 sec
```
```
test 29
Start 29: test-shutdown
29: Test command: /usr/bin/wine "z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/bin/dbus-run-session.exe" "--config-file=z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/test/data/valid-config-files/tmp-session.conf" "--dbus-daemon=z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/bin/dbus-daemon.exe" "z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/bin/test-shutdown.exe" "--tap"
29: Environment variables:
29: DBUS_SESSION_BUS_PID=
29: DBUS_SESSION_BUS_ADDRESS=
29: DBUS_FATAL_WARNINGS=1
29: DBUS_TEST_DAEMON=z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/bin/dbus-daemon.exe
29: DBUS_TEST_DATA=z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/test/data
29: DBUS_TEST_HOMEDIR=z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/dbus
29: Test timeout computed to be: 180
29: dbus[45]: error: Failed to start message bus: Failed to open "z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/share\dbus-1\session.conf": Path not found.
29: Backtrace:
29: 0 0xf7eff067
29: 1 0x7bc8191e in ntdll
29: 2 0x7bc88b45 in ntdll
29: 3 0x7bc8b05f in ntdll
29: 4 0x7b47832a in kernel32
29: 5 0x7b4784b3 in kernel32
29: 6 0x7b47851d in kernel32
29: 7 dump_backtrace+0xa6 [../../dbus/dbus-sysdeps-win.c:2790] in libdbus-1-3
29: 8 _dbus_print_backtrace+0xb [../../dbus/dbus-sysdeps-win.c:2801] in libdbus-1-3
29: 9 _dbus_abort+0xc [../../dbus/dbus-sysdeps.c:93] in libdbus-1-3
29: 10 _dbus_warn+0x6e [../../dbus/dbus-internals.c:259] in libdbus-1-3
29: 11 main+0xa97 [../../bus/main.c:705] in dbus-daemon
29: 12 EntryPoint+0xffffffffffffffff in dbus-daemon
29: 13 0x7b463e32 in kernel32
29: 14 0x7b4661ac in kernel32
29: 15 0x7b463e3e in kernel32
29: ok 1
29: ok 2
29: ok 3
29: 1..3
29/29 Test #29: test-shutdown .................... Passed 0.34 sec
```
From what I see, the test starts a dbus daemon with a preconfigured session bus that does not match the default autolaunch address. So the client automatically starts an additional dbus daemon, with `--session' as argument.
Since it does not find the requested session configuration file in `z:/builds/xxx/dbus/ci-build-production-i686-w64-mingw32/share\dbus-1\session.conf`, it is terminated. The test case passes because it connects to the previously started dbus daemon.Ralf HabackerRalf Habackerhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/241tests for OOM behaviour are skipped on Windows with CMake but not Autotools2020-04-25T08:23:29ZSimon McVittietests for OOM behaviour are skipped on Windows with CMake but not Autotools```
% git grep DBUS_WIN_FIXME
README.win:- the code wrapped with DBUS_WIN_FIXME should be inspected if it required for windows
bus/dispatch.c:#ifdef DBUS_WIN_FIXME
cmake/config.h.cmake:# define DBUS_WIN_FIXME 1
dbus/dbus-memory.c:#ifdef ...```
% git grep DBUS_WIN_FIXME
README.win:- the code wrapped with DBUS_WIN_FIXME should be inspected if it required for windows
bus/dispatch.c:#ifdef DBUS_WIN_FIXME
cmake/config.h.cmake:# define DBUS_WIN_FIXME 1
dbus/dbus-memory.c:#ifdef DBUS_WIN_FIXME
```
cmake/config.h.cmake is only used under CMake, not Autotools.
The practical result is that:
* The test for GetConnectionUnixProcessID is skipped when built for Windows with CMake, but not when built for Windows with Autotools. This is certainly wrong: GetConnectionUnixProcessID() is a cross-platform feature now, so we should fix that test so that it can pass on Windows (which I think !55 does) and enable it everywhere.
* The tests for what happens when malloc() returns NULL are skipped when built for Windows with CMake, but not when built for Windows with Autotools. We should decide whether libdbus on Windows aims to be robust against out-of-memory conditions.
* If it does, we should run these tests, even though they're slow (you can temporarily skip them for quicker testing with the `DBUS_TEST_MALLOC_FAILURES` environment variable).
* If it doesn't, we should probably make `dbus_malloc()` and friends abort on out-of-memory, like GLib's equivalents do, when running on Windows.https://gitlab.freedesktop.org/dbus/dbus/-/issues/240test-bus (intermittently?) fails on Wine if all tests are run2019-01-16T12:14:08ZSimon McVittietest-bus (intermittently?) fails on Wine if all tests are run@rhabacker wrote:
> test-bus running with wine fails with one test
> ```
> ~/src/dbus-cmake-cross-wine-build> DBUS_TEST_HOMEDIR=z:$PWD DBUS_TEST_DATA=z:$PWD/test/data /usr/bin/wine "z:/home/ralf.habacker/src/dbus-cmake-cross-wine-build...@rhabacker wrote:
> test-bus running with wine fails with one test
> ```
> ~/src/dbus-cmake-cross-wine-build> DBUS_TEST_HOMEDIR=z:$PWD DBUS_TEST_DATA=z:$PWD/test/data /usr/bin/wine "z:/home/ralf.habacker/src/dbus-cmake-cross-wine-build/bin/test-bus.exe"
> ...
> ok 18 - bus_dispatch_test_conf:valid-config-files/debug-allow-all.conf - check_shell_service_success_auto_start
> ok 19 - bus_dispatch_test_conf:valid-config-files/debug-allow-all.conf
> ok 20 - dispatch
> ok 21 - dispatch did not leak memory
> # Running test: activation-service-reload
> ##temp dir 'C:\users\ralf.habacker\Temp'
> ##bus_context_new ''
> ##bus_config_load ''
> ##_dbus_file_get_contents ''
> dbus-daemon[8]: warning: Failed to create debug bus context from configuration file valid-config-files/debug-allow-all.conf: Failed to open "": Pfad nicht gefunden.
> ##bus_context_new ''
> ##bus_config_load ''
> ##_dbus_file_get_contents ''
> dbus-daemon[8]: warning: Failed to create debug bus context from configuration file valid-config-files/debug-allow-all.conf: Failed to open "": Pfad nicht gefunden.
> ok 22 - activation-service-reload
> not ok 23 - activation-service-reload leaked 2 blocks
> ok 24 # SKIP fd-passing not supported on this platform
> # 1/24 tests failed
> 1..24
> ```
>
> Before running the test I added some debug output to the code, which are identifiable by a prefix '##'.
>
> It happens only when running all test, but not if running a single test e.g. using
>
> ```
> DBUS_TEST_ONLY=dispatch ...
> ```
> or
> ```
> DBUS_TEST_ONLY=activation-service-reload ...
> ```
>
> In the error case the character string from the config_file parameter given to bus_context_new() is empty or has cryptic content, which let me assume that config_file seems to be free'd or points to invalid memory.
>
> It should also be noted that in the 'run all tests' case memory leaks are reported in test 23
>
> ```
> not ok 23 - activation-service-reload leaked 2 blocks
> ```https://gitlab.freedesktop.org/dbus/dbus/-/issues/239test-bus fails when built for Windows with CMake2020-11-13T07:41:38ZSimon McVittietest-bus fails when built for Windows with CMakeOn !23, @rhabacker wrote:
```
2/20 Test #2: test-bus .........................***Failed 5.70 sec
```
This is apparently reproducible on Windows 7, on Windows 10, and when cross-compiling under Linux and running the tests with Wine...On !23, @rhabacker wrote:
```
2/20 Test #2: test-bus .........................***Failed 5.70 sec
```
This is apparently reproducible on Windows 7, on Windows 10, and when cross-compiling under Linux and running the tests with Wine.
test-bus is large and complicated so I'm not really surprised. !1 breaks it into smaller pieces: it would be interesting to see which of them fail.https://gitlab.freedesktop.org/dbus/dbus/-/issues/238test-sysdeps fails (freezes) when built for Windows with CMake2019-01-16T12:14:08ZSimon McVittietest-sysdeps fails (freezes) when built for Windows with CMakeOn !23, @rhabacker wrote:
```
18/20 Test #18: test-sysdeps ..................... Freeze
```
This is apparently reproducible on Windows 7, on Windows 10, and when cross-compiling under Linux and running the tests with Wine.On !23, @rhabacker wrote:
```
18/20 Test #18: test-sysdeps ..................... Freeze
```
This is apparently reproducible on Windows 7, on Windows 10, and when cross-compiling under Linux and running the tests with Wine.https://gitlab.freedesktop.org/dbus/dbus/-/issues/216building tests fails on Windows (msys2)2019-04-18T15:38:43ZBugzilla Migration Userbuilding tests fails on Windows (msys2)## Submitted by Vincent Torri
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107051)](https://bugs.freedesktop.org/show_bug.cgi?id=107051)**
## Description
when i compile d-bus on Windows (MSYS2 + mingw-w64), using th...## Submitted by Vincent Torri
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107051)](https://bugs.freedesktop.org/show_bug.cgi?id=107051)**
## Description
when i compile d-bus on Windows (MSYS2 + mingw-w64), using the autotools, i get that error:
/usr/bin/mkdir -p -m 700 XDG_RUNTIME_DIR
/usr/bin/mkdir: impossible de modifier les droits de « XDG_RUNTIME_DIR »: Permission denied
(translation : impossible to modify access rights)
trying this command directly in MSYS2 gives the same error. So passing -m 700 seems wrong when using MSYS2
Vincent Torri
Version: 1.12https://gitlab.freedesktop.org/dbus/dbus/-/issues/191sysdeps-win: _dbus_get_autolaunch_address prints to stdout/stderr2020-04-27T12:16:49ZBugzilla Migration Usersysdeps-win: _dbus_get_autolaunch_address prints to stdout/stderr## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#103756)](https://bugs.freedesktop.org/show_bug.cgi?id=103756)**
## Description
The coding convention for the dbus library is to report erro...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#103756)](https://bugs.freedesktop.org/show_bug.cgi?id=103756)**
## Description
The coding convention for the dbus library is to report errors through a DBusError (analogous to a GError or a C++ exception) so that they can be caught and handled by application code in whatever way is most appropriate for the application. In particular, this avoids corrupting stdout/stderr if the application is using them for something machine-readable.
However, the Windows implementation of _dbus_get_autolaunch_address() doesn't do that consistently:
if (!SearchPathA(dbus_module_path, daemon_name, NULL, sizeof(dbus_exe_path), dbus_exe_path, &lpFile))
{
dbus_set_error_const (error, DBUS_ERROR_FAILED, "could not find dbus-daemon executable");
retval = FALSE;
fprintf (stderr, "please add the path to %s to your PATH environment variable\n", daemon_name);
fprintf (stderr, "or start the daemon manually\n\n");
}
(This is after Bug #103601 - before that, it used printf to stdout, which was worse, because stdout is more likely to be used for machine-readable output.)
The warnings that are currently printed to stderr should probably move into the message part of the DBusError. It's OK for a DBusError to be reasonably long.
In library code, we should only emit warnings to stderr as a last resort when nothing else is possible (and if we do that, we should use _dbus_warn() instead of fprintf).
I'm not intending to fix this myself, since I don't develop on Windows and so can't meaningfully test this.
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/149Memory leak when running test-(d)bus test on Windows2023-01-06T09:14:30ZBugzilla Migration UserMemory leak when running test-(d)bus test on Windows## Submitted by yfei
Assigned to **D-Bus Maintainers**
**[Link to original bug (#95191)](https://bugs.freedesktop.org/show_bug.cgi?id=95191)**
## Description
Created attachment 123326
Log from running "nmake check" on Win64 build ...## Submitted by yfei
Assigned to **D-Bus Maintainers**
**[Link to original bug (#95191)](https://bugs.freedesktop.org/show_bug.cgi?id=95191)**
## Description
Created attachment 123326
Log from running "nmake check" on Win64 build using VS2013.
When running test-dbus spawn, I get memory leak errors. Full unit test output is attached. Test was run in Win10 x64, VS2013 compiler, "nmake check".
**Attachment 123326**, "Log from running "nmake check" on Win64 build using VS2013.":
[LastTest.log](/uploads/3a1add486baccbb67fbe4e2182a24610/LastTest.log)
Version: 1.10
See also #279Ralf HabackerRalf Habackerhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/99W32: syslogging function is broken, syslog test segfaults2019-12-06T00:11:46ZBugzilla Migration UserW32: syslogging function is broken, syslog test segfaults## Submitted by LRN
Assigned to **D-Bus Maintainers**
**[Link to original bug (#75861)](https://bugs.freedesktop.org/show_bug.cgi?id=75861)**
## Description
AFAIU, this is because it uses the same buffer to print to and from.
Ver...## Submitted by LRN
Assigned to **D-Bus Maintainers**
**[Link to original bug (#75861)](https://bugs.freedesktop.org/show_bug.cgi?id=75861)**
## Description
AFAIU, this is because it uses the same buffer to print to and from.
Version: 1.5https://gitlab.freedesktop.org/dbus/dbus/-/issues/88various thread-safety issues involving static variables2020-11-14T10:22:53ZBugzilla Migration Uservarious thread-safety issues involving static variables## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#68610)](https://bugs.freedesktop.org/show_bug.cgi?id=68610)**
## Description
Created attachment 84714
_dbus_get_tmpdir: be thread-safe
Sharin...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#68610)](https://bugs.freedesktop.org/show_bug.cgi?id=68610)**
## Description
Created attachment 84714
_dbus_get_tmpdir: be thread-safe
Sharing a static variable between threads is not safe in general,
and this function is used in the shared libdbus (for nonce files),
so it can't rely on being single-threaded.
---
This patch probably only applies to master. For dbus-1.6, we can have a simpler patch, because _DBUS_LOCK() can't fail.
~~**Patch 84714**~~, "_dbus_get_tmpdir: be thread-safe":
[0001-_dbus_get_tmpdir-be-thread-safe.patch](/uploads/2a204aa5854bb934dc5240f0370f43a6/0001-_dbus_get_tmpdir-be-thread-safe.patch)
Version: 1.5