After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 679656 - win32: port gtester to work on windows
win32: port gtester to work on windows
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gtest
unspecified
Other Windows
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2012-07-10 00:55 UTC by Marc-Andre Lureau
Modified: 2018-05-24 14:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
win32: port gtester to work on windows (3.69 KB, patch)
2012-07-10 00:56 UTC, Marc-Andre Lureau
none Details | Review

Description Marc-Andre Lureau 2012-07-10 00:55:23 UTC
The changes are mostly trivial. Only G_SPAWN_LEAVE_DESCRIPTORS_OPEN
can't easily be fixed, the spawn-helper closes all fd > 3 if not set.
There is no callback like on Linux to unset the CLOEXEC, or prevent
from closing the fd. Perhaps we need an extended
spawn_async_with_pipes() that would take a list of fd to leave open?
Comment 1 Marc-Andre Lureau 2012-07-10 00:56:39 UTC
Created attachment 218372 [details] [review]
win32: port gtester to work on windows
Comment 2 Colin Walters 2012-07-10 13:08:21 UTC
Review of attachment 218372 [details] [review]:

What about g_test_trap_fork()?  You're just going to get a spam of "not implemented" messages with this patch right?

That API was frankly a terrible idea even on Unix, because of the fork-versus-threads problem, and GLib uses threads.

::: glib/gtester.c
@@ +43,3 @@
+#ifndef WEXITSTATUS
+#define WEXITSTATUS(S) (((S) & 0xff00) >> 8)
+#endif

Ugh.  We should really have g_spawn_check_status() or something; I thought about extracting it from the gsubprocess work ( bug 672102 ).
Comment 3 Colin Walters 2012-07-10 15:46:42 UTC
(In reply to comment #2)

> Ugh.  We should really have g_spawn_check_status() or something; I thought
> about extracting it from the gsubprocess work ( bug 672102 ).

Done in bug 679691 ; however I didn't actually port GTester to it because it does really bizarre things with the exit status.
Comment 4 Marc-Andre Lureau 2012-07-10 16:43:38 UTC
(In reply to comment #3)
> (In reply to comment #2)
> 
> > Ugh.  We should really have g_spawn_check_status() or something; I thought
> > about extracting it from the gsubprocess work ( bug 672102 ).
> 
> Done in bug 679691 ; however I didn't actually port GTester to it because it
> does really bizarre things with the exit status.

yeah, I was copying this change from a mingw developer gcc patch, but it looks wrong to be to check the exist status like we do on Unix.

glib returns GetExitCodeProcess() in child cb, which not giving us much information about program termination, except with the value STILL_ACTIVE (259):

http://msdn.microsoft.com/en-us/library/windows/desktop/ms683189%28v=vs.85%29.aspx

That would be already a start for the  g_spawn_check_status() ?
Comment 5 GNOME Infrastructure Team 2018-05-24 14:20:22 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/569.