Re: Is tar Broken In 10.3-STABLE?

2016-07-05 Thread Jan Mikkelsen 
Hi,

Tar should complain and die if an input path doesn’t exist. So, no, the 
behaviour you’re seeing isn’t broken. See also:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205358 


This bug has been fixed upstream seems to have been imported into stable/10 in 
r302075. From the commit message:
- tar and cpio should fail if an input file named on the command line is
  missing (vendor issue 708)
I agree the message could be a bit clearer about what’s going on!

Regards,

Jan.


> On 6 Jul 2016, at 02:39, Tim Daneliuk  wrote:
> 
> I just upgraded to r302342 today to verify a problem I saw 
> after a 10.3-STABLE upgrade yesterday.  Upgrade was 
> accomplished via makeworld/kernel & installworld/kernel.
> 
> 
> When using tar with the -T argument to provide a list 
> of backup sources, it blows out with the following 
> error if a source in the file list is missing:
> 
>   tar: INTERNAL ERROR: Function 'archive_read_disk_open' invoked with archive 
> structure in state 'header', should be in state 'new/closed': Unknown error: 
> -1
> 
> In the past, tar would make some noise if it was asked
> to copy a nonexistent file or directory, but it would 
> continue the remainder of the archive operation.
> 
> Thoughts?
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

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

Is tar Broken In 10.3-STABLE?

2016-07-05 Thread Tim Daneliuk 
I just upgraded to r302342 today to verify a problem I saw 
after a 10.3-STABLE upgrade yesterday.  Upgrade was 
accomplished via makeworld/kernel & installworld/kernel.


When using tar with the -T argument to provide a list 
of backup sources, it blows out with the following 
error if a source in the file list is missing:

   tar: INTERNAL ERROR: Function 'archive_read_disk_open' invoked with archive 
structure in state 'header', should be in state 'new/closed': Unknown error: -1

In the past, tar would make some noise if it was asked
to copy a nonexistent file or directory, but it would 
continue the remainder of the archive operation.

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

Re: A faulty program corrupts some its data preventing correct core generation (Failed to write core file for process postgres (error 14))

2016-07-05 Thread Maxim Sobolev 
Seems like candidate for the MFC into releng/10.3 and appropriate errata
entry?

-Max

On Tue, Jul 5, 2016 at 4:48 AM, Konstantin Belousov 
wrote:

> On Mon, Jul 04, 2016 at 10:26:25PM -0700, Maxim Sobolev wrote:
> > Hi all, investigating some random postgresql-9.1.21 server crashes on
> > FreeBSD 10.3, we've started seeing those after upgrading from postgres
> > 9.1.18 on more than one system, so hardware (e.g. RAM issues) are very
> > unlikely. I suspect that postgres is at fault, however I am also curious
> > how could it be that kernel is not capable of generating core file when
> > application does something silly? Is it that some ELF-related data
> > structures got corrupted or something else? Are we protecting the page
> > where ELF header is mapped with R/O flag? I am looking at possibly
> > recreating this by poking around elf header(s), seeing if I can corrupt
> it
> > in a similar manner reliably, any pointers or suggestions are
> appreciated.
> >
> > Jun 27 04:10:18 dal12 kernel: Failed to write core file for process
> > postgres (error 14)
> > Jun 27 04:10:18 dal12 kernel: pid 41361 (postgres), uid 70: exited on
> > signal 11
> > Jul  1 05:21:46 dal12 kernel: Failed to write core file for process
> > postgres (error 14)
> > Jul  1 05:21:46 dal12 kernel: pid 1722 (postgres), uid 70: exited on
> signal
> > 11
> >
> > #define EFAULT  14  /* Bad address */
> >
> > The resulting files are truncated and is not really usable for anything.
> > We've seen the same issue
> >
> > -rw---1 pgsql wheel 1310720 Jun 27 04:10
> postgres.41361.core
> > -rw---1 pgsql wheel 1310720 Jul  1 05:21
> postgres.1722.core
> >
> > [ssp-root@dal12 /var/tmp]$ sudo gdb711 postgres postgres.1722.core
> > GNU gdb (GDB) 7.11 [GDB v7.11 for FreeBSD]
> > Copyright (C) 2016 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html
> > >
> > 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 "x86_64-portbld-freebsd10.3".
> > 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 postgres...(no debugging symbols found)...done.
> > BFD: Warning: /var/tmp/postgres.1722.core is truncated: expected core
> file
> > size >= 51712, found: 1310720.
> > [New LWP 100261]
> > Core was generated by `postgres'.
> > Program terminated with signal SIGSEGV, Segmentation fault.
> > #0  0x000800cfba67 in ?? () from /lib/libthr.so.3
> > (gdb) where
> > #0  0x000800cfba67 in ?? () from /lib/libthr.so.3
> > Backtrace stopped: Cannot access memory at address 0x7fffdd08
> > (gdb) q
> >
> https://lists.freebsd.org/pipermail/freebsd-stable/2016-June/084877.html
>
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: A faulty program corrupts some its data preventing correct core generation (Failed to write core file for process postgres (error 14))

2016-07-05 Thread Konstantin Belousov 
On Mon, Jul 04, 2016 at 10:26:25PM -0700, Maxim Sobolev wrote:
> Hi all, investigating some random postgresql-9.1.21 server crashes on
> FreeBSD 10.3, we've started seeing those after upgrading from postgres
> 9.1.18 on more than one system, so hardware (e.g. RAM issues) are very
> unlikely. I suspect that postgres is at fault, however I am also curious
> how could it be that kernel is not capable of generating core file when
> application does something silly? Is it that some ELF-related data
> structures got corrupted or something else? Are we protecting the page
> where ELF header is mapped with R/O flag? I am looking at possibly
> recreating this by poking around elf header(s), seeing if I can corrupt it
> in a similar manner reliably, any pointers or suggestions are appreciated.
> 
> Jun 27 04:10:18 dal12 kernel: Failed to write core file for process
> postgres (error 14)
> Jun 27 04:10:18 dal12 kernel: pid 41361 (postgres), uid 70: exited on
> signal 11
> Jul  1 05:21:46 dal12 kernel: Failed to write core file for process
> postgres (error 14)
> Jul  1 05:21:46 dal12 kernel: pid 1722 (postgres), uid 70: exited on signal
> 11
> 
> #define EFAULT  14  /* Bad address */
> 
> The resulting files are truncated and is not really usable for anything.
> We've seen the same issue
> 
> -rw---1 pgsql wheel 1310720 Jun 27 04:10 postgres.41361.core
> -rw---1 pgsql wheel 1310720 Jul  1 05:21 postgres.1722.core
> 
> [ssp-root@dal12 /var/tmp]$ sudo gdb711 postgres postgres.1722.core
> GNU gdb (GDB) 7.11 [GDB v7.11 for FreeBSD]
> Copyright (C) 2016 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 "x86_64-portbld-freebsd10.3".
> 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 postgres...(no debugging symbols found)...done.
> BFD: Warning: /var/tmp/postgres.1722.core is truncated: expected core file
> size >= 51712, found: 1310720.
> [New LWP 100261]
> Core was generated by `postgres'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x000800cfba67 in ?? () from /lib/libthr.so.3
> (gdb) where
> #0  0x000800cfba67 in ?? () from /lib/libthr.so.3
> Backtrace stopped: Cannot access memory at address 0x7fffdd08
> (gdb) q
> 
https://lists.freebsd.org/pipermail/freebsd-stable/2016-June/084877.html
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Recent stable: bsnmpd eats up memory and cpu

2016-07-05 Thread Mark Huizer 
On Tue, Jul 05, 2016 at 10:38:23AM +0200, Mark Huizer wrote:
> On Mon, May 02, 2016 at 12:01:07AM +0200, Wolfgang Zenker wrote:
> > Hi,
> > 
> > after updating some 10-STABLE systems a few days ago, I noticed that on
> > two of those systems bsnmpd started to use up a lot of cpu time, and the
> > available memory shrinked until rendering the system unusable. Killing
> > bsnmpd stops the cpu usage but does not free up memory.
> > Both affected systems are amd64, one having moved from r297555 to
> > r298723, the other from r297555 to r298722. Another amd64 system
> > that went from r297555 to r298722 appears to be not affected.
> > The two affected systems are on an internal LAN segment and there
> > is currently no application connecting to snmp on those machines.
> > 
> > What would be useful debugging data to collect in this case?
> 
> I saw a resembling thing here after upgrading to 10-stable yesterday.
> I noticed bsnmp running at 30 to 40% cpu continuously, resembling what I 
> found here:
> 
> https://forums.freebsd.org/threads/37045/

Sorry, I meant https://forums.freebsd.org/threads/56235/

Greetings

Mark
-- 
Nice testing in little China...
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Recent stable: bsnmpd eats up memory and cpu

2016-07-05 Thread Mark Huizer 
On Mon, May 02, 2016 at 12:01:07AM +0200, Wolfgang Zenker wrote:
> Hi,
> 
> after updating some 10-STABLE systems a few days ago, I noticed that on
> two of those systems bsnmpd started to use up a lot of cpu time, and the
> available memory shrinked until rendering the system unusable. Killing
> bsnmpd stops the cpu usage but does not free up memory.
> Both affected systems are amd64, one having moved from r297555 to
> r298723, the other from r297555 to r298722. Another amd64 system
> that went from r297555 to r298722 appears to be not affected.
> The two affected systems are on an internal LAN segment and there
> is currently no application connecting to snmp on those machines.
> 
> What would be useful debugging data to collect in this case?

I saw a resembling thing here after upgrading to 10-stable yesterday.
I noticed bsnmp running at 30 to 40% cpu continuously, resembling what I found 
here:

https://forums.freebsd.org/threads/37045/

After ktrace-ing the process I noticed it was doing sysctl stuff all the time 
and a more close
look showed that it was freaking out on the CD device without a medium.

So I inserted a CD in the device, and bsnmp went back to normal.

"Interesting". So far I didn't notice memory issues.

Mark
-- 
Nice testing in little China...
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"