[Geany-Devel] Ping on Bug #943 - windows build command

[Nick Treleaven]

On 07/10/2013 20:07, Matthew Brush wrote:
> On 13-10-07 08:31 AM, Nick Treleaven wrote:
>> On 05/10/2013 15:40, Matthew Brush wrote:
>>> On 13-10-05 07:06 AM, Nick Treleaven wrote:
>>>>> It was last year, but I think it wasn't just with dmd, although that
>>>>> triggered it the most, and it only happened when dmd wrote more than a
>>>>> certain amount to stderr (cascading errors). It was very suspicious
>>>>> that
>>>>> the custom spawn code works until there are too many errors, at least
>>>>> with dmd.
>>>>
>>>> One person reported it on the devel list. See:
>>>> http://lists.geany.org/pipermail/devel/2011-July/004845.html
>>>>
>>>> Unfortunately I missed that mail at the time, but I tried the provided
>>>> fix before committing my system() change, and I remember it didn't fix
>>>> all the issues with blocking and/or hanging Geany I had.
>>>>
>>>
>>> That was going to be my guess for the deadlock, once the buffers fill up
>>> they have to be drained or else can't keep writing to input. The same
>>> issue should apply to any spawning method we use probably (ie. GSpawn).
>>
>> Did we get deadlock with g_spawn? I'm only aware of missing output.
>>
>
> It sounded like what was described by Josh in your link:
>
> "The problem seems to be that pipes are only 4kb buffered by default, so
> any process needing to write more than this would block while writing to
> stdout and Geany would kill it, as it wasn't reading the pipes until
> after the process exited."

But that link is talking about the custom spawning, and provides a patch 
to it. You must be confused, g_spawn shouldn't have that issue (only by 
coincidence, and I know of no evidence it has).

>
>>> So with the pull request adding system() as a fallback/hidden
>>> preference, maybe we could just drop the win32 API code altogether,
>>> switch back to using the same codepath as all platforms (ie. GLib async
>>> spawning) and if people experience issues, we can use as further data
>>> points to troubleshoot GLib async spawning and we can recommend they try
>>> the system() option[1] as a workaround?
>>
>> system() is *synchronous*, so we couldn't remove the SYNC_SPAWN code and
>> have it as an option.
>>
>
> I mean to remove the win32_spawn function (as it existed before the
> system() hack), the one that was left orphaned in win32.c and renamed it
> to broken_win32_spawn() that uses the win32 API rather than GLib
> spawning or system().

It actually wasn't orphaned if env was set, but I get you.

>>> IMO, any function in our code base prefixed with _broken, that no one
>>> wants to touch, and looses platform-independence for our code, should
>>> just be deleted[2] :)
>>
>> I thought you said it was most important to fix the common case, that's
>> why I made the PR.
>>
>
> I imagine the most common case would be that g_spawn_async_with_pipes()
> works. I've used it a number of times on Windows without issues and I've
> not found online or encountered any issues with lost output that's being
> claimed as the reason for all these work-arounds for it.

Can you please try running a command that outputs *both* stderr and 
stdout? See my reply to the parent message about make object and build.o.

>>> BTW, did you try undefining SYNC_SPAWN lately to see if async spawning
>>> still doesn't work for you now? If so and it doesn't, what Windows
>>> version and GLib versions do you have?
>>
>> I just tried it. Running build on a C file:
>>
>> gcc -Wall -c "build.c" (in directory: C:\git\geany\src)
>> Compilation failed.
>> gcc: error: "build.c": Invalid argument
>> gcc: fatal error: no input files
>> compilation terminated.
>>
>> No idea why gcc says that, also tried for another file in parent
>> directory.
>>
>> Running build on a D file just says 'Compilation failed' without
>> reporting the line compilation fails on.
>>
>> Windows Vista. GTK 2.22.0, GLib 2.26.0.
>>
>
> GTK+ 2.22 is over 3 years old by now, FWIW.

OK. Try to reproduce my problem with your newer gtk then.