This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug hurd/5904] New: Executable locking is failing
- From: "myprasanna at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 10 Mar 2008 14:51:13 -0000
- Subject: [Bug hurd/5904] New: Executable locking is failing
- Reply-to: sourceware-bugzilla at sourceware dot org
This is a query rather than a bug report.
Could be a bug, i never know. Sorry if misplaced.
Who prevents an executable from opening it's own binary?
Is it the executable options that GCC checks, or does
the linux loader by default lock any executing executable?
Now i am facing this following situation:
a.cpp
{
fopen("a", "wb") => fails
// create a new file a2 and write something
system("mv a2 a"); ==> works!
// after the mv
fopen("a", "wb") => works
}
Can you please tell me what's going on here?
If that's a lock that was broken once the mv completed,
what happens to portions of executable on disk?
What kinds of problems can this lead to? or is it completely
swapped out from disk before mv starts?
Thanks in advance,
myprasanna@gmail.com
--
Summary: Executable locking is failing
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: hurd
AssignedTo: roland at gnu dot org
ReportedBy: myprasanna at gmail dot com
CC: glibc-bugs at sources dot redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=5904
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.