bugThe GNU Hurd - Bugs: bug #49730, /proc/PID/environ returns I/O...

 
 

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

Submitter:  Brent Baccala <baccala>
Submitted:  Tue 29 Nov 2016 07:42:00 AM UTC
   
 
Category:  Hurd Servers Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  None Privacy:  Public
Assigned to:  None Originator Name: 
Open/Closed:  Open Reproducibility:  None
Size (loc):  None Planned Release:  None
Effort:  0.00
Wiki-like text discussion box: 


* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 31 Oct 2017 01:10:03 AM UTC, comment #1: 

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)

Joshua Branson <joshuabranson>
Tue 29 Nov 2016 07:42:00 AM UTC, original submission:  

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?

Brent Baccala <baccala>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #42303:  proc-io-error.sh added by joshuabranson (219B - application/x-shellscript)
file #39096:  get_arg_locations.c added by baccala (380B - application/txt)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by joshuabranson (Updated the item)
  • -email is unavailable- added by baccala (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-10-31 joshuabranson Attached File- Added proc-io-error.sh, #42303
    2016-11-29 baccala Attached File- Added get_arg_locations.c, #39096

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code