Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • G GLib
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 853
    • Issues 853
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 54
    • Merge requests 54
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GNOMEGNOME
  • GLib
  • Issues
  • #16
Closed
Open
Issue created Nov 06, 2003 by Bugzilla@bugzilla-migration💬Reporter

gspawn.c file descriptor handling

Submitted by Morten Welinder

Link to original bug (#126373)

Description

I am having a hard time convincing myself that gspawn handles file descriptors correctly.

Assume that one or more of fds 0,1,2 are closed before any of the public APIs are called. Since Unix allocates descriptors on a lowest-first basis, these will likely be allocated by gspawn.c's pipe/open.

Then do_exec will unexpectedly close them when it does "sane_dup2 (stdin_fd, 0)". (That call closes fd 0 unless stdin_fd is already zero.) Not good.

Of course, if I could find a case that fails, it would be better, :-(

FYI, Emacs contains code to avoid this problem. Basically, file descriptors created using pipe or open are relocated up above 2 using dup.

Assignee
Assign to
Time tracking