[Bug threads/28065] FAIL: gdb.threads/access-mem-running-thread-exit.exp: all-stop: access mem (print global_var after writing again, inf=1, iter=354)

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28065

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bp at alien8 dot de

--- Comment #19 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Pedro Alves from comment #18)
> Created attachment 13554 [details]
> attach-2.c
> 
> Adjusted version of testcase that:
> 
>  - closes fd
>  - does not have main thread call pthread_exit.  
>  - also expects ESRCH.  I saw that a couple times.
> 
> Otherwise, still fails the same way.

Hi Boris,

We're seeing this reproducer fail like this:
...
$ gcc -pthread access-2.c
$ ./a.out 
pread64 res: 0
a.out: access-2.c:45: get_global_var: Assertion `res == 4' failed.
Aborted (core dumped)
...
and we're trying to understand if this is a kernel bug or not.

What happens:
- we do an open ("/proc/$pid/task/$tid/mem"), and this succeeds, so
  we get a file descriptor.
- then we try to read from the file descriptor, but this returns 0, in other
  words we have EOF.

The fact that read doesn't complete could be explained by tid exiting
before/during the read.

The question is then whether EOF is the correct failure mode.  Shouldn't we
expect read to return -1, with errno set to EBADF or EINVAL or some such?

-- 
You are receiving this mail because:
You are on the CC list for the bug.