[bug #49730] /proc/PID/environ returns I/O errors on read attempts

[Joshua Branson]

Follow-up Comment #1, bug #49730 (project hurd):

I think I understand the main things that were said in the first paragraph.  I
wrote a short bash program to try to run 

cat /proc/936/environ 

1000 times.  The program seemed to run fine, but I'm not sure if it got an I/O
error.  I assume that if it did get an I/O error, the program would have
crashed, and it did not crash...

So hopefully I'm not wasting everybody's time by commenting on this bug.

(file #42303)
___

Additional Item Attachment:

File name: proc-io-error.sh   Size:0 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #49730] /proc/PID/environ returns I/O errors on read attempts

[Brent Baccala]

URL:
  

 Summary: /proc/PID/environ returns I/O errors on read
attempts
 Project: The GNU Hurd
Submitted by: baccala
Submitted on: Tue 29 Nov 2016 07:42:00 AM GMT
Category: Hurd Servers
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Reproducibility: None
  Size (loc): None
 Planned Release: None
  Effort: 0.00
Wiki-like text discussion box: 

___

Details:

I'm having problems retrieving process environment from /proc.  Something like
"cat /proc/936/environ" often (but not always) returns an I/O error, while
"msgport --getenv -p 936" works fine.  I'm not sure exactly which processes
suffer from this, but translators seem particularly vulnerable.

Studying the problem with rpctrace, it seems that there are two different ways
to obtain a process's environment.  The proc server hold a pointer to the
environment array (in the process's address space, not its own), and then
vm_read's it to answer proc_procgetenv RPCs.  This is how procfs does it, and
this is what isn't working.

I've written a short program (attached) to fetch the argument locations and
print them.  Comparing this output to /proc/PID/maps shows that on the
affected processes, the addresses appear sane, but do not correspond to mapped
memory locations, thus the I/O errors.

The other way to get a process's environment is to fetch the process's msg
port and query it using a msg_get_environment RPC.  The msgport program does
this, and is able to successfully retrieve environment information.

Related: Do we need two different ways to retrieve a process's environment?



___

File Attachments:


---
Date: Tue 29 Nov 2016 07:42:00 AM GMT  Name: get_arg_locations.c  Size: 380B  
By: baccala



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/