On 7/23/2019 9:51 AM, Jon Turney wrote:
> On 22/07/2019 15:59, Ken Brown wrote:
>> With the test version of gdb, attempting to debug bash fails as follows:
>>
>> $ gdb bash
>> GNU gdb (GDB) (Cygwin 8.2.1-1) 8.2.1
>> [...]
>> Reading symbols from bash...Reading symbols from
>> /usr/lib/debug//usr/bin/bash.exe.dbg...done.
>> done.
>> (gdb) r -c ls
>> Starting program: /usr/bin/bash -c ls
>> [...]
>> /usr/bin/bash: initialize_job_control: getpgrp failed: No error
>> [...]
>> [Inferior 1 (process 31876) exited with code 01]
>>
>> This problem doesn't occur with gdb-8.1.1-1.
> Thanks for reporting this.
>
> I had also tripped over this problem recently: It seems that changes in gdb
> (bisection lands on [1]) mean that any call to getpgrp() in the inferior
> fails
> (this can be demonstrated with a test program that just calls that).
I can't reproduce that with the following test program:
$ cat getpgrp_test.c
#include <unistd.h>
int
main ()
{
pid_t t = getpgrp ();
}
> I believe this is behaviour is caused by some kind of defect in the cygwin
> DLL,
> but I haven't made much progress in investigating it. (I don't really
> understand
> how the inferior gets into a state where getpgrp() fails, which isn't really
> supposed to happen...)
POSIX says that getpgrp() never fails, but Cygwin's getpgrp() can in fact fail.
I'm about to send a proposed fix to cygwin-patches. I've just checked that the
bash example succeeds with my patch installed.
BTW, I think there's also a bash bug here. The bash-4.4.12 source code has the
following in jobs.c:
shell_pgrp = getpgid (0);
if (shell_pgrp == -1)
{
sys_error (_("initialize_job_control: getpgrp failed"));
exit (1);
}
At first glance this might seem OK, since getpgid() is allowed to fail. But a
macro earlier in the code redefines getpgid() in terms of getpgrp(), which is
not supposed to fail.
I've added Eric to the CC in case he wants to follow up on this.
Ken
