Re: Would O_APPEND for /dev/null be possible?

2017-08-09 Thread Steffen Nurpmeso 
Good evening.

Bryan Drewery  wrote:
 |On 8/7/2017 2:36 PM, Steffen Nurpmeso wrote:
 |> I can open a file with "a+", which, for this software, means
 |> "O_RDWR | O_APPEND | O_CREAT | n_O_NOFOLLOW" on Linux, Solaris and
 |> OpenBSD, but FreeBSD complains, i think because O_APPEND.  (I
 ...
 |> # cat uh.c
 |> #include 
 |> #include 
 |> 
 |> int main() {
 |> int fd;
 |> 
 |> fd = open("/dev/null", O_RDWR | O_APPEND | O_CREAT | O_NOFOLLOW);
 |> if (fd == -1)
 |> err(1, "open");
 |> return 0;
 |>}
 |
 |> # truss ./uh
 |...
 |> openat(AT_FDCWD,"/dev/null",O_RDWR|O_APPEND|O_NOFOLLOW|O_CREAT,0376252\
 |> 0) = 3 (0x3)
 |
 |Seems to work fine.

Puh. ...  I really looked, logically this codepath should not use
locking, so i thought ...  Hmm, this is even more complicated than
i thought, wait, i have to debug that.  And: it turns out that
a fseek(3) on the descriptor opened not only fails but sets the
ferror(3) state of the FILE!  I would need to look into the
standard whether this behaviour is correct, but in any case we are
not prepared for that, and neither of Linux, Solaris nor OpenBSD
enter this condition.

(What i did is with the MUA i maintain use the rather useless
`write' command which by default writes to /dev/null, this stacks
over c_write()[1] over to save1()[2] which does a lot of stuff,
anyway /dev/null opened via n_fopen_any()[3] to MBOX preparation
call n_folder_mbox_prepare_append()[4] which is defined here[5].
This never made problems yet, but of course i admit it is
a generalization (of several instances of rather identical code in
former versions of this MUA) which is truly bad and will,
hopefully, in a distant future be replaced by a "Mailbox" object
which then has some kind of Mailbox::append() (or prepare_append()
first if anything else fails), and that could act better for some
special files.  Anyway, that not today.)

  [1] https://git.sdaoden.eu/cgit/s-nail.git/tree/cmd-write.c#n380
  [2] https://git.sdaoden.eu/cgit/s-nail.git/tree/cmd-write.c#n56
  [3] https://git.sdaoden.eu/cgit/s-nail.git/tree/cmd-write.c#n145
  [4] https://git.sdaoden.eu/cgit/s-nail.git/tree/cmd-write.c#n168
  [5] https://git.sdaoden.eu/cgit/s-nail.git/tree/folder.c#n900

Ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Would O_APPEND for /dev/null be possible?

2017-08-09 Thread Bryan Drewery 
On 8/7/2017 2:36 PM, Steffen Nurpmeso wrote:
> I can open a file with "a+", which, for this software, means
> "O_RDWR | O_APPEND | O_CREAT | n_O_NOFOLLOW" on Linux, Solaris and
> OpenBSD, but FreeBSD complains, i think because O_APPEND.  (I
> think only because the VM does not survive resumes and other
> pauses here, which frustrated me over time.  It is old VM.)
> I mean, it seems i have to sprinkle more /dev/null string
> comparisons all over the place, but i wonder whether that really
> belongs there.. for /dev/null?

> # cat uh.c
> #include 
> #include 
> 
> int main() {
> int fd;
> 
> fd = open("/dev/null", O_RDWR | O_APPEND | O_CREAT | O_NOFOLLOW);
> if (fd == -1)
> err(1, "open");
> return 0;
> }

> # truss ./uh
...
> openat(AT_FDCWD,"/dev/null",O_RDWR|O_APPEND|O_NOFOLLOW|O_CREAT,03762520) 
> = 3 (0x3)

Seems to work fine.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: [bmake] bmake sigint handling causing tty corruption

2017-08-09 Thread Bryan Drewery 
On 7/20/2017 10:33 AM, Simon J. Gerraty wrote:
> Konstantin Belousov  wrote:
>> I just find is somewhat strange that make initiates a new session.
> 
> In jobs mode it does - to ensure the child and all progeny can be killed
> in one fell swoop.
> In compat mode it does not, but that does not mean the child cannot do
> so.
> 
>> Did you verified that enabling the wait code in make(1) fixes the issue ?
> 
> FWIW it is a reasonably simple patch to make to wait for child to exit
> before self termination.
> 

There's a similar bug with compat vs jobs mode in that stdout/stderr
actually being a TTY is not conveyed to the jobs children.  Gmake
conveys both stdout and stderr as TTY to children [1].  This causes
clang's color diagnostics to not be enabled by default with jobs mode
since it is looking at stderr for being a TTY.  It works fine in compat
mode.
I've been working around it with this to avoid the detection:
> /etc/make.conf:CFLAGS.clang+=   -fcolor-diagnostics
Ccache also wanted to pass this flag along if stderr was a TTY, which
meant that jobs mode and compat mode ended up using different caches
since one had the flag and the other did not.  I fixed the ccache port
to not hashing the flag entirely though in ports r408673 / 2016-02.

I had written this patch to "fix" bmake a few years ago,
https://people.freebsd.org/~bdrewery/patches/bmake-job-stderr-tty.patch.
 However I took another look at the problem last year and came up with
an entirely different patch.  I think the problem with my naive patch
there is that stderr/stdin are actually passed through the same pipe for
jobs mode, so my second attempt was to create a separate stderr pipe
similar to the existing job.outPipe, rather than the naive patch just
sending stderr to the real one.  I ran into more issues with that though
with interspersed messages IIRC.  I abandoned the work for that.

[1] bmake vs gmake:

> # cat Makefile
> blah:
> @if [ -t 0 ]; then echo "0 is a TTY"; fi
> @if [ -t 1 ]; then echo "1 is a TTY"; fi
> @if [ -t 2 ]; then echo "2 is a TTY"; fi
> # make
> Building /usr/obj/root/git/freebsd/tmp/blah
> 0 is a TTY
> # make -j2
> Building /usr/obj/root/git/freebsd/tmp/blah
> # gmake
> 0 is a TTY
> 1 is a TTY
> 2 is a TTY
> # gmake -j2
> 0 is a TTY
> 1 is a TTY
> 2 is a TTY
> #


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: Apparent race in buildworld (head/amd64, r322214 -> r322304)

2017-08-09 Thread Bryan Drewery 
On 8/9/2017 12:35 PM, David Wolfskill wrote:
> On Wed, Aug 09, 2017 at 12:22:20PM -0700, Bryan Drewery wrote:
>>> /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s
>> ... 
>>
>> This should fix it:
>> https://people.freebsd.org/~bdrewery/patches/gcc_s-install-race.diff
>>
>> The problem has consistently been, from your reports, that gcc_s is
>> being installed to WORLDTMP *while* something is trying to link to it.
> 
> Yeah, that doesn't seem like something that's likely to have
> deterministic results.
> 
>> ...
>>> --- lib/libc++__L ---
>>> /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s
>>>
>>> --- lib/libgcc_s__L ---^M   
>>>   
>> ...
>>> --- all_subdir_secure/lib/libcrypto/engines/libsureware ---^M   
>>>   
>>> /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s^M  
>>>   
>>
>>
>>
>> By default 'install' unlinks the file and then copies over the new file.
>>  Using PRECIOUSLIB we get the -S flag to install which is atomic in its
>> installation.
>>
>> Note the patch is not what I will commit. At Isilon we changed our
>> install to always use -S for library installation, but not to force schg
>> on.  I am considering making that change the default, to use -S for all
>> libraries.
> 
> From an (admittedly) naive perspective, it seems to me that enforcing
> "atomic installation" for file system objects that are to be used
> during the build (or install) makes more sense than firing and
> hoping for the best.  :-}
> 

It also fixes some runtime crashes while concurrently running
installworld to a live system.  One that we ran into a lot was an NSS
module being used for user lookup that another concurrent install would
use while the module was being overwritten.  It would see a bogus file
during the install.

>> -- 
>> Regards,
>> Bryan Drewery
>>
> 
> Thanks! :-)
> 
> Peace,
> david
> 


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: Apparent race in buildworld (head/amd64, r322214 -> r322304)

2017-08-09 Thread David Wolfskill 
On Wed, Aug 09, 2017 at 12:22:20PM -0700, Bryan Drewery wrote:
> > /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s
> ... 
> 
> This should fix it:
> https://people.freebsd.org/~bdrewery/patches/gcc_s-install-race.diff
> 
> The problem has consistently been, from your reports, that gcc_s is
> being installed to WORLDTMP *while* something is trying to link to it.

Yeah, that doesn't seem like something that's likely to have
deterministic results.

> ...
> > --- lib/libc++__L ---
> > /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s
> > 
> > --- lib/libgcc_s__L ---^M   
> >   
> ...
> > --- all_subdir_secure/lib/libcrypto/engines/libsureware ---^M   
> >   
> > /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s^M  
> >   
> 
> 
> 
> By default 'install' unlinks the file and then copies over the new file.
>  Using PRECIOUSLIB we get the -S flag to install which is atomic in its
> installation.
> 
> Note the patch is not what I will commit. At Isilon we changed our
> install to always use -S for library installation, but not to force schg
> on.  I am considering making that change the default, to use -S for all
> libraries.

From an (admittedly) naive perspective, it seems to me that enforcing
"atomic installation" for file system objects that are to be used
during the build (or install) makes more sense than firing and
hoping for the best.  :-}

> -- 
> Regards,
> Bryan Drewery
> 

Thanks! :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
If we wish to eliminate sources of Fake News, start at the top: D. Trump.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Apparent race in buildworld (head/amd64, r322214 -> r322304)

2017-08-09 Thread Bryan Drewery 
>   /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s


On 8/9/2017 10:57 AM, David Wolfskill wrote:
> On Wed, Aug 09, 2017 at 10:49:04AM -0700, Bryan Drewery wrote:
>> ...
>>> on one machine, but the other never had an issue.  On the "failing" one,
>>> a re-start of the buildworld completed (apparently) successfully.
>>
>> Yeah, I've gotten reports of this one for years.  I fixed a few problems
>> with it in the past but something else must have creeped in.
> 
> Or I just got "lucky." :-)
> 
>> I don't believe it is related to META_MODE though.
> 
> Fair enough; I pointed it out just in case it might be relevant.  (I try
> to avoid hiding possibly-relevant information when I'm trying to work
> with someone to solve a problem.  I know that's weird, but... :-} )
> 
>> The last time I fixed this (AFAIK) it was related to an early error
>> being ignored.  I'll review your log to see if I can find anything like
>> that.
> 
> Cool.  FWIW, the scheduler will see 8 cores on each machine, so the
> "make buildworld" will have been "make -j16 buildworld" (on each).
> 
>> 
> 

This should fix it:
https://people.freebsd.org/~bdrewery/patches/gcc_s-install-race.diff

The problem has consistently been, from your reports, that gcc_s is
being installed to WORLDTMP *while* something is trying to link to it.

> --- gnu/lib/libgcc__L ---
> Building /common/S4/obj/usr/src/world32/usr/src/gnu/lib/libgcc/_libinstall
> --- kerberos5/lib/libhx509__L ---
> Building 
> /common/S4/obj/usr/src/world32/usr/src/kerberos5/lib/libhx509/keyset.So
> --- secure/lib/libssl__L ---
> /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s
> 
> 
> Building /common/S3/obj/usr/src/world32/usr/src/gnu/lib/libgcc/_libinstall
> --- lib/ncurses/ncursesw__L ---
> Building 
> /common/S3/obj/usr/src/world32/usr/src/lib/ncurses/ncursesw/nc_panel.po
> --- lib/ncurses/ncurses__L ---
> Building 
> /common/S3/obj/usr/src/world32/usr/src/lib/ncurses/ncurses/comp_parse.po
> --- lib/ncurses/ncursesw__L ---
> Building 
> /common/S3/obj/usr/src/world32/usr/src/lib/ncurses/ncursesw/resizeterm.po
> --- lib/libc++__L ---
> /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s
> 
> --- lib/libgcc_s__L ---^M 
> Building /common/S4/obj/usr/src/world32/usr/src/lib/libgcc_s/_libinstall^M
> --- kerberos5/lib/libwind__L ---^M
> --- obj ---^M 
> --- secure/lib/libcrypto__L ---^M 
> --- all_subdir_secure/lib/libcrypto/engines/libatalla ---^M   
> /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s^M
> cc: error: linker command failed with exit code 1 (use -v to see invocation)^M
> --- all_subdir_secure/lib/libcrypto/engines/libsureware ---^M 
> /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s^M



By default 'install' unlinks the file and then copies over the new file.
 Using PRECIOUSLIB we get the -S flag to install which is atomic in its
installation.

Note the patch is not what I will commit. At Isilon we changed our
install to always use -S for library installation, but not to force schg
on.  I am considering making that change the default, to use -S for all
libraries.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: Userland problems in 12-CURRENT

2017-08-09 Thread Bob Bishop 
Just copying this reply to the list.

> On 9 Aug 2017, at 11:41, Filippo Moretti  wrote:
> 
> I could not find a bios option,the kernel does report PAE as a CPU option
> 
>   
> Features=0xbfebfbff
>   Features2=0x441d
> thank you
> Filippo
> 
> On Wednesday, August 9, 2017, 12:36:47 PM GMT+2, Bob Bishop  
> wrote:
> 
> 
> Hi,
> 
> > On 9 Aug 2017, at 11:19, Filippo Moretti  wrote:
> > 
> > [...]
> > Further I did succesfully install a PAE kernel but the OS only finds the 
> > same 3G ram as standard kernel insted of the 4 G available.Are there other 
> > procedures in order to enable the 4G ram available?ThanksFilippo
> 
> 
> Maybe there is a BIOS option to enable PAE? Does the kernel report PAE in the 
> CPU options at boot?
> 
> --
> Bob Bishop
> r...@gid.co.uk
> 
> 
> 
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Userland problems in 12-CURRENT

2017-08-09 Thread Bob Bishop 
Hi,

> On 9 Aug 2017, at 11:19, Filippo Moretti  wrote:
> 
> [...]
> Further I did succesfully install a PAE kernel but the OS only finds the same 
> 3G ram as standard kernel insted of the 4 G available.Are there other 
> procedures in order to enable the 4G ram available?ThanksFilippo

Maybe there is a BIOS option to enable PAE? Does the kernel report PAE in the 
CPU options at boot?

--
Bob Bishop
r...@gid.co.uk




___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Userland problems in 12-CURRENT

2017-08-09 Thread Filippo Moretti 
FreeBSD sting 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r321685M: Sun Jul 30 
08:49:42 CEST 2017 root@sting:/usr/obj/usr/src/sys/STING_VT  i386
I have a problems with chromium and smtube bott exit with segmentation fault 
chromium does'n produce any core.Smtube corefollows:GNU gdb (GDB) 8.0 [GDB v8.0 
for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/smtube...(no debugging symbols 
found)...done.
[New LWP 100652]
[New LWP 100938]
[New LWP 100939]
[New LWP 100940]
[New LWP 100941]
[New LWP 100942]
Core was generated by `smtube'.Program terminated with signal SIGSEGV, 
Segmentation fault.
#0  0x2a5c4d55 in ?? () from /usr/local/lib/qt5/libQt5WebKit.so.5
[Current thread is 1 (LWP 100652)]
(gdb) where
#0  0x2a5c4d55 in ?? () from /usr/local/lib/qt5/libQt5WebKit.so.5
#1  0x28def484 in ?? () from /usr/local/lib/qt5/libQt5WebKit.so.5
#2  0x2910da99 in ?? () from /usr/local/lib/qt5/libQt5WebKit.so.5
#3  0x290f7ff8 in ?? () from /usr/local/lib/qt5/libQt5WebKit.so.5
#4  0x290f51fe in ?? () from /usr/local/lib/qt5/libQt5WebKit.so.5
#5  0x290f7c62 in ?? () from /usr/local/lib/qt5/libQt5WebKit.so.5
#6  0x28e02694 in QWebFrameAdapter::load(QNetworkRequest const&, 
QNetworkAccessManager::Operation, QByteArray const&) ()
   from /usr/local/lib/qt5/libQt5WebKit.so.5
#7  0x280fa6b7 in QWebFrame::load(QUrl const&) ()
   from /usr/local/lib/qt5/libQt5WebKitWidgets.so.5
#8  0x28107ad8 in QWebView::load(QUrl const&) ()
   from /usr/local/lib/qt5/libQt5WebKitWidgets.so.5#9  0x0807d768 in ?? ()
#10 0x08089054 in ?? ()
#11 0x0805853a in ?? ()
#12 0x080583f8 in ?? ()
#13 0x in ?? ()

Further I did succesfully install a PAE kernel but the OS only finds the same 
3G ram as standard kernel insted of the 4 G available.Are there other 
procedures in order to enable the 4G ram available?ThanksFilippo

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"