On 09/16/16 09:25, Sam Varshavchik wrote:
>> >
>> Do you happen to know the Bugzilla?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1374917
Thanks much.
--
You're Welcome Zachary Quinto
signature.asc
Description: OpenPGP digital signature
--
users mailing list
Ed Greshko writes:
On 09/16/16 07:09, Sam Varshavchik wrote:
> Tom Horsley writes:
>
>> On Wed, 14 Sep 2016 06:47:28 -0400
>> Sam Varshavchik wrote:
>>
>> > But why even bother
>> > mapping anything. I would think that accessing an unmapped region would
>> > result in a SIGSEGV just as well.
>>
On 09/16/16 07:09, Sam Varshavchik wrote:
> Tom Horsley writes:
>
>> On Wed, 14 Sep 2016 06:47:28 -0400
>> Sam Varshavchik wrote:
>>
>> > But why even bother
>> > mapping anything. I would think that accessing an unmapped region would
>> > result in a SIGSEGV just as well.
>>
>> Ah-HA! A
Tom Horsley writes:
On Wed, 14 Sep 2016 06:47:28 -0400
Sam Varshavchik wrote:
> But why even bother
> mapping anything. I would think that accessing an unmapped region would
> result in a SIGSEGV just as well.
Ah-HA! A question I can answer :-).
You need to map something because otherwise
On Wed, 14 Sep 2016 06:47:28 -0400
Sam Varshavchik wrote:
> But why even bother
> mapping anything. I would think that accessing an unmapped region would
> result in a SIGSEGV just as well.
Ah-HA! A question I can answer :-).
You need to map something because otherwise the program itself
Tom Horsley writes:
On Tue, 13 Sep 2016 22:05:18 -0400
Sam Varshavchik wrote:
> [heap]
> 7 7fa2a000-7fa2a0085000 532.00 Kb rw-p 00:00 0
> 8 7fa2a0085000-7fa2a40065004.00 Kb ---p 00:00 0
> 9
On Tue, 13 Sep 2016 22:05:18 -0400
Sam Varshavchik wrote:
> [heap]
> 7 7fa2a000-7fa2a0085000 532.00 Kb rw-p 00:00 0
> 8 7fa2a0085000-7fa2a40065004.00 Kb ---p 00:00 0
> 9 7fa2a800-7fa2a806f000 444.00 Kb
Tom Horsley writes:
On Tue, 13 Sep 2016 19:10:13 -0400
Tom Horsley wrote:
> I'm not exactly sure about any of that though. If I
> look at some maps files, there always seems to be
> one of these ---p regions somewhere in the middle
> of each shared library.
I found this:
On Tue, 13 Sep 2016 19:10:13 -0400
Tom Horsley wrote:
> I'm not exactly sure about any of that though. If I
> look at some maps files, there always seems to be
> one of these ---p regions somewhere in the middle
> of each shared library.
I found this:
On Tue, 13 Sep 2016 18:46:50 -0400
Sam Varshavchik wrote:
> half of them are "---p" mappings, which I do not
> understand, a private mapping without read and write privileges?
I think that corresponds to an intentional "hole" in
the address space where attempted access results in
a segfault
Rick Stevens writes:
On 09/13/2016 04:06 AM, Sam Varshavchik wrote:
>
> Freshly restarted named:
>
> 4.7.2:
>
> PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND
> 29156 named 20 0 702528 83324 6360 S 12.5 2.1 0:00.23 named
>
> 4.6.7:
>
> PID USER PR
Tom Horsley writes:
On Tue, 13 Sep 2016 09:56:08 -0700
Rick Stevens wrote:
> Yeah, the virtual usage is significantly bigger, the resident part
> slightly bigger and the shared segment is actually smaller. Weird.
You could compare the /proc/pid/maps files for both cases and
see which memory
On Tue, 13 Sep 2016 09:56:08 -0700
Rick Stevens wrote:
> Yeah, the virtual usage is significantly bigger, the resident part
> slightly bigger and the shared segment is actually smaller. Weird.
You could compare the /proc/pid/maps files for both cases and
see which memory segment(s) were bigger.
On 09/13/2016 04:06 AM, Sam Varshavchik wrote:
> Rick Stevens writes:
>
>> On 09/10/2016 08:09 AM, Sam Varshavchik wrote:
>> > Sam Varshavchik writes:
>> >
>> >> Tom Horsley writes:
>> >>
>> >>> On Sat, 10 Sep 2016 10:20:57 -0400
>> >>> Sam Varshavchik wrote:
>> >>>
>> >>> > All-righty, this must
Rick Stevens writes:
On 09/10/2016 08:09 AM, Sam Varshavchik wrote:
> Sam Varshavchik writes:
>
>> Tom Horsley writes:
>>
>>> On Sat, 10 Sep 2016 10:20:57 -0400
>>> Sam Varshavchik wrote:
>>>
>>> > All-righty, this must be something about this particular named-chroot
>>> > configuration…
>>>
On 09/10/2016 08:09 AM, Sam Varshavchik wrote:
> Sam Varshavchik writes:
>
>> Tom Horsley writes:
>>
>>> On Sat, 10 Sep 2016 10:20:57 -0400
>>> Sam Varshavchik wrote:
>>>
>>> > All-righty, this must be something about this particular named-chroot
>>> > configuration…
>>>
>>> In the "check the
Sam Varshavchik writes:
Tom Horsley writes:
On Sat, 10 Sep 2016 10:20:57 -0400
Sam Varshavchik wrote:
> All-righty, this must be something about this particular named-chroot
> configuration…
In the "check the dumb stuff first" category, might want to
run memtest and check the SMART info on
Tom Horsley writes:
On Sat, 10 Sep 2016 10:20:57 -0400
Sam Varshavchik wrote:
> All-righty, this must be something about this particular named-chroot
> configuration…
In the "check the dumb stuff first" category, might want to
run memtest and check the SMART info on the disk. Always a
chance
On Sat, 10 Sep 2016 10:20:57 -0400
Sam Varshavchik wrote:
> All-righty, this must be something about this particular named-chroot
> configuration…
In the "check the dumb stuff first" category, might want to
run memtest and check the SMART info on the disk. Always a
chance the code got
Ed Greshko writes:
On 09/10/16 20:15, Sam Varshavchik wrote:
> Can't get any more broken than a segfault at startup :-)
>
> Looking at the carnage in /var/log/messages, it broke so bad that even
systemd-coredump
> choked on itself, and failed to do whatever it wanted to do. Impressive.
>
>
On 09/10/16 20:15, Sam Varshavchik wrote:
> Can't get any more broken than a segfault at startup :-)
>
> Looking at the carnage in /var/log/messages, it broke so bad that even
> systemd-coredump
> choked on itself, and failed to do whatever it wanted to do. Impressive.
>
> Booted back to 4.6.7
Can't get any more broken than a segfault at startup :-)
Looking at the carnage in /var/log/messages, it broke so bad that even
systemd-coredump choked on itself, and failed to do whatever it wanted to
do. Impressive.
Booted back to 4.6.7 to get things going again. Don't really have much
22 matches
Mail list logo
