Re: Strange fopen() behaviour
Just to follow up, this was fixed with v1.9 of src/lib/libc/stdio/findfp.c
Thanks Maxim !
I've cc'd -current as I think something more sinister is going on.
To recap, I'm having trouble running xsane on -current from about two
days ago. fopen() is failing...
The attached patch exposes more about what's wrong. Interestingly
enough, the file it's trying to create is in /tmp (mode 1777,
separate filesystem), and according to truss:
lstat("/tmp//preview-level-0-15-b924dc",0xbfbfe894) ERR#2 'No such file or
directory'
umask(0x7f) = 7 (0x7)
/tmp//preview-level-0-15-b924dc17767-microtek:_dev_scanner.ppm: could not create
for preview-level 0: No such file or directory
write(2,0xbfbfe48c,128) = 128 (0x80)
getuid() = 15 (0xf)
lstat("/tmp//preview-level-1-15-jNO6zx",0xbfbfe894) ERR#2 'No such file or
directory'
umask(0x7f) = 127 (0x7f)
/tmp//preview-level-1-15-jNO6zx09158-microtek:_dev_scanner.ppm: could not create
for preview-level 1: No such file or directory
write(2,0xbfbfe48c,128) = 128 (0x80)
getuid() = 15 (0xf)
lstat("/tmp//preview-level-2-15-CO6k7w",0xbfbfe894) ERR#2 'No such file or
directory'
umask(0x7f) = 127 (0x7f)
break(0x8134000) = 0 (0x0)
/tmp//preview-level-2-15-CO6k7w39017-microtek:_dev_scanner.ppm: could not create
for preview-level 2: No such file or directory
write(2,0xbfbfe48c,128) = 128 (0x80)
fopen() is failing after calling lstat() (I assume via _open()) !!!
As if the "wb" didn't mean O_CREAT ??!? Very strange.
[.]
And just to top it all, I see this in my daily report (first time
I've ever seen it on this machine...):
dev.lan.Awfulhak.org kernel log messages:
microuptime() went backwards (18415.166882 - 18415.158249)
microuptime() went backwards (18490.192910 - 18490.187579)
microuptime() went backwards (19572.644000 - 19572.638237)
microuptime() went backwards (19878.637972 - 19878.637330)
microuptime() went backwards (20043.869158 - 20043.868971)
microuptime() went backwards (20074.159108 - 20074.152253)
microuptime() went backwards (20210.078270 - 20210.072448)
--
Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org
http://www.Awfulhak.org brian@[uk.]OpenBSD.org
Don't _EVER_ lose your sense of humour !
--
Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org
http://www.Awfulhak.org brian@[uk.]OpenBSD.org
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Strange fopen() behaviour
In message [EMAIL PROTECTED] Farid Hajji writes: : dev.lan.Awfulhak.org kernel log messages: : microuptime() went backwards (18415.166882 - 18415.158249) : microuptime() went backwards (18490.192910 - 18490.187579) : microuptime() went backwards (19572.644000 - 19572.638237) : microuptime() went backwards (19878.637972 - 19878.637330) : microuptime() went backwards (20043.869158 - 20043.868971) : microuptime() went backwards (20074.159108 - 20074.152253) : microuptime() went backwards (20210.078270 - 20210.072448) : I'm also seing this as of CURRENT-2001-01-27 and later: : pcm1: hwptr went backwards 36 - 0 : pcm1: hwptr went backwards 40 - 16 : pcm1: hwptr went backwards 2084 - 2048 : pcm1: hwptr went backwards 2092 - 2064 That's different. It is a sound thing that's related to the really crappy interrupt performance that we have in current. You'll likely see it as far back as october or so (I was seeing them at BSDCON). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Strange fopen() behaviour
dev.lan.Awfulhak.org kernel log messages: microuptime() went backwards (18415.166882 - 18415.158249) microuptime() went backwards (18490.192910 - 18490.187579) microuptime() went backwards (19572.644000 - 19572.638237) microuptime() went backwards (19878.637972 - 19878.637330) microuptime() went backwards (20043.869158 - 20043.868971) microuptime() went backwards (20074.159108 - 20074.152253) microuptime() went backwards (20210.078270 - 20210.072448) I'm also seing this as of CURRENT-2001-01-27 and later: pcm1: hwptr went backwards 36 - 0 pcm1: hwptr went backwards 40 - 16 pcm1: hwptr went backwards 2084 - 2048 pcm1: hwptr went backwards 2092 - 2064 Strange... -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Strange fopen() behaviour
On Wed, Feb 07, 2001 at 12:34:18AM +0100, Farid Hajji wrote: I'm also seing this as of CURRENT-2001-01-27 and later: pcm1: hwptr went backwards 36 - 0 pcm1: hwptr went backwards 40 - 16 pcm1: hwptr went backwards 2084 - 2048 pcm1: hwptr went backwards 2092 - 2064 These have existed "forever"..different problem. Kris PGP signature
Strange fopen() behaviour (was: xsane patch to maintainer)
Hi,
Would you mind if I commit the attached patch for the xsane port ?
It makes sense - rather than dropping a core when fopen() fails (and
fclose() is called with a NULL arg). It happens when your home
directory isn't writable :-/
I've cc'd -current as I think something more sinister is going on.
To recap, I'm having trouble running xsane on -current from about two
days ago. fopen() is failing...
The attached patch exposes more about what's wrong. Interestingly
enough, the file it's trying to create is in /tmp (mode 1777,
separate filesystem), and according to truss:
lstat("/tmp//preview-level-0-15-b924dc",0xbfbfe894) ERR#2 'No such file or directory'
umask(0x7f) = 7 (0x7)
/tmp//preview-level-0-15-b924dc17767-microtek:_dev_scanner.ppm: could not create for
preview-level 0: No such file or directory
write(2,0xbfbfe48c,128) = 128 (0x80)
getuid() = 15 (0xf)
lstat("/tmp//preview-level-1-15-jNO6zx",0xbfbfe894) ERR#2 'No such file or directory'
umask(0x7f) = 127 (0x7f)
/tmp//preview-level-1-15-jNO6zx09158-microtek:_dev_scanner.ppm: could not create for
preview-level 1: No such file or directory
write(2,0xbfbfe48c,128) = 128 (0x80)
getuid() = 15 (0xf)
lstat("/tmp//preview-level-2-15-CO6k7w",0xbfbfe894) ERR#2 'No such file or directory'
umask(0x7f) = 127 (0x7f)
break(0x8134000) = 0 (0x0)
/tmp//preview-level-2-15-CO6k7w39017-microtek:_dev_scanner.ppm: could not create for
preview-level 2: No such file or directory
write(2,0xbfbfe48c,128) = 128 (0x80)
fopen() is failing after calling lstat() (I assume via _open()) !!!
As if the "wb" didn't mean O_CREAT ??!? Very strange.
Anyway, here's the patch if you're interested. I'll look into things
further on Wednesday.
Cheers.
--
Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org
http://www.Awfulhak.org brian@[uk.]OpenBSD.org
Don't _EVER_ lose your sense of humour !
--- src/xsane-preview.c.origSun Jan 14 15:35:06 2001
+++ src/xsane-preview.c Tue Feb 6 03:03:18 2001
@@ -2802,6 +2802,7 @@
int i;
char buf[256];
char filename[PATH_MAX];
+ FILE *fp;
DBG(DBG_proc, "preview_new\n");
@@ -2830,9 +2831,17 @@
if (preview_make_image_path(p, sizeof(filename), filename, i)=0)
{
umask(0177); /* create temporary file with "-rw---"
permissions */
- fclose(fopen(filename, "wb")); /* make sure file exists, b = binary mode for
win32 */
- umask(XSANE_DEFAULT_UMASK); /* define new file permissions */
- p-filename[i] = strdup(filename);/* store filename */
+ fp = fopen(filename, "wb"); /* make sure file exists, b = binary mode for
+win32 */
+ if (fp == NULL) {
+fprintf(stderr, "%s: could not create for preview-level %d: %s\n", filename,
+i, strerror(errno));
+p-filename[i] = NULL;
+ }
+ else
+ {
+fclose(fp);
+umask(XSANE_DEFAULT_UMASK);/* define new file permissions */
+p-filename[i] = strdup(filename);/* store filename */
+ }
}
else
{
Re: Strange fopen() behaviour
I've cc'd -current as I think something more sinister is going on.
To recap, I'm having trouble running xsane on -current from about two
days ago. fopen() is failing...
The attached patch exposes more about what's wrong. Interestingly
enough, the file it's trying to create is in /tmp (mode 1777,
separate filesystem), and according to truss:
lstat("/tmp//preview-level-0-15-b924dc",0xbfbfe894) ERR#2 'No such file or directory'
umask(0x7f)= 7 (0x7)
/tmp//preview-level-0-15-b924dc17767-microtek:_dev_scanner.ppm: could not create for
preview-level 0: No such file or directory
write(2,0xbfbfe48c,128)= 128 (0x80)
getuid() = 15 (0xf)
lstat("/tmp//preview-level-1-15-jNO6zx",0xbfbfe894) ERR#2 'No such file or directory'
umask(0x7f)= 127 (0x7f)
/tmp//preview-level-1-15-jNO6zx09158-microtek:_dev_scanner.ppm: could not create for
preview-level 1: No such file or directory
write(2,0xbfbfe48c,128)= 128 (0x80)
getuid() = 15 (0xf)
lstat("/tmp//preview-level-2-15-CO6k7w",0xbfbfe894) ERR#2 'No such file or directory'
umask(0x7f)= 127 (0x7f)
break(0x8134000) = 0 (0x0)
/tmp//preview-level-2-15-CO6k7w39017-microtek:_dev_scanner.ppm: could not create for
preview-level 2: No such file or directory
write(2,0xbfbfe48c,128)= 128 (0x80)
fopen() is failing after calling lstat() (I assume via _open()) !!!
As if the "wb" didn't mean O_CREAT ??!? Very strange.
[.]
And just to top it all, I see this in my daily report (first time
I've ever seen it on this machine...):
dev.lan.Awfulhak.org kernel log messages:
microuptime() went backwards (18415.166882 - 18415.158249)
microuptime() went backwards (18490.192910 - 18490.187579)
microuptime() went backwards (19572.644000 - 19572.638237)
microuptime() went backwards (19878.637972 - 19878.637330)
microuptime() went backwards (20043.869158 - 20043.868971)
microuptime() went backwards (20074.159108 - 20074.152253)
microuptime() went backwards (20210.078270 - 20210.072448)
--
Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org
http://www.Awfulhak.org brian@[uk.]OpenBSD.org
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Strange fopen() behaviour (was: xsane patch to maintainer)
lstat("/tmp//preview-level-0-15-b924dc",0xbfbfe894) ERR#2 'No such file or directory'
^^
surely this is not nice!! My guess is that the double slash is confusing
everything...
Anyway, I'm more interested in below:
@@ -2830,9 +2831,17 @@
if (preview_make_image_path(p, sizeof(filename), filename, i)=0)
{
umask(0177); /* create temporary file with "-rw---"
permissions */
- fclose(fopen(filename, "wb")); /* make sure file exists, b = binary mode for
win32 */
- umask(XSANE_DEFAULT_UMASK);/* define new file permissions */
- p-filename[i] = strdup(filename);/* store filename */
+ fp = fopen(filename, "wb");/* make sure file exists, b = binary mode for
win32 */
+ if (fp == NULL) {
+fprintf(stderr, "%s: could not create for preview-level %d: %s\n",
filename, i, strerror(errno));
+p-filename[i] = NULL;
+ }
+ else
+ {
+fclose(fp);
+umask(XSANE_DEFAULT_UMASK); /* define new file permissions */
+p-filename[i] = strdup(filename);/* store filename */
+ }
I REALLY hope above code is NEVER EVER run as root, as this is a great
recipe for interesting failures...
/me hands Brian a few symlinks to /etc/master.passwd from /tmp
If you are patching it, make sure you get it right, you'd do
everybody a big favor.
Bye,
Andrea
--
It is easier to fix Unix than to live with NT.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
