GCC 4.2.1 on 5.8 stable: printf enables merging linked lists?

[Pavan Maddamsetti]

/*
 * Here 's the code. Try commenting out the line that says "WTF mate!"
 * On my machine, the loop never returns. Somehow printf makes it work.
 * Compiler bug or not? Please compile and confirm.
 */

#include 
#include 

typedef struct List List;
struct List {
int data;
List *next;
};

List *new(int);
List *add(List *, List *);
List *merge(List *, List *);

int
main(void)
{
List *a, *b, *t, *p;
a = b = t = p = NULL;

int i;
for (i = 0; i < 10; i += 2)
a = add(a, new(i));
for (i = 1; i < 10; i += 2)
b = add(b, new(i));

printf("Printing a...\n");
for (t = a; t != NULL; t = t->next)
printf("%d ", t->data);
printf("\n");

printf("Printing b...\n");
for (t = b; t != NULL; t = t->next)
printf("%d ", t->data);
printf("\n");

printf("Merging a and b...");
p = merge(a, b);
printf("done.\n");

printf("Printing...\n");
for (t = p; t != NULL; t = t->next)
printf("%d ", t->data);
printf("\n");

exit(0);
}

List *
new(int data)
{
List *newp;
newp = malloc(sizeof(List));
newp->data = data;
newp->next = NULL;
return newp;
}

List *
add(List *listp, List *newp)
{
List *p;

if (listp == NULL)
return newp;
for (p = listp; p->next != NULL; p = p->next)
;
p->next = newp;
return listp;
}

List *
merge(List *ap, List *bp)
{
List *listp;
List **last;
last = 

for (;;) {
if (ap == NULL) {
(*last)->next = bp;
break;
} else if (bp == NULL) {
(*last)->next = ap;
break;
}
printf("\nWTF mate!\n"); /* problem here */
if (ap->data < bp->data) {
(*last)->next = ap;
ap = ap->next;
} else {
(*last)->next = bp;
bp = bp->next;
}
last = &((*last)->next);
}
return listp->next;
}

Re: bgpd in snapshot from 4 feb.

[mxb]

I actually run sysmerge.
It added new users/groups, updated certs.
Rest of configs I merged. Seen nothing about rc-scripts.

> On 7 feb. 2016, at 22:01, Claudio Jeker  wrote:
>
> On Sun, Feb 07, 2016 at 07:53:01PM +0100, mxb wrote:
>> Hey,
>> bgpd from snap of 4 feb. fails to start (according to rc):
>>
>> shell# /etc/rc.d/bgpd start
>> bgpd(failed)
>
> You forgot to run sysmerge. The rc scripts changed on what they pgrep to
> see if the parent process is running. Since the rc script is unable to
> find the process it reports failed eventhough all is OK.
>
>> shell# ps aux|grep bgp
>> _bgpd11880  0.0  0.0  1220  1804 ??  Sp 7:46PM0:00.02 bgpd:
>> session engine (bgpd)
>> _bgpd11350  0.0  0.0   920  1816 ??  Sp 7:46PM0:00.02 bgpd:
route
>> decision engine (bgpd)
>> root 18325  0.0  0.0   864  1484 ??  Is 7:46PM0:00.01
>> /usr/sbin/bgpd
>> root 13125  0.0  0.0   176   356 p0  R+ 7:47PM0:00.00 grep bgp
>>
>>
>> rcctl reports the same, but ???ps aux|grep bgp??? after looks even worse:
>>
>> shell# rcctl restart bgpd
>> bgpd(failed)
>>
>> shell]# ps aux|grep bgp
>> root 18325  0.0  0.0   864  1484 ??  Ss 7:46PM0:00.01
>> /usr/sbin/bgpd
>> _bgpd11880  0.8  0.1  2120  3244 ??  Sp 7:46PM0:00.66 bgpd:
>> session engine (bgpd)
>> _bgpd11350  0.0  0.0   952  1864 ??  Sp 7:46PM0:00.04 bgpd:
route
>> decision engine (bgpd)
>> _bgpd 2567  0.7  0.1  2108  3404 ??  Sp 7:50PM0:00.62 bgpd:
>> session engine (bgpd)
>> _bgpd 4216  0.0  0.0   944  1840 ??  Sp 7:50PM0:00.01 bgpd:
route
>> decision engine (bgpd)
>> root 13197  0.0  0.0   864  1484 ??  Ss 7:50PM0:00.01
>> /usr/sbin/bgpd
>> root  3906  0.0  0.0   292   512 p0  R+ 7:50PM0:00.00 grep bgp
>>
>
> --
> :wq Claudio

Re: bgpd in snapshot from 4 feb.

[Claudio Jeker]

On Sun, Feb 07, 2016 at 07:53:01PM +0100, mxb wrote:
> Hey,
> bgpd from snap of 4 feb. fails to start (according to rc):
> 
> shell# /etc/rc.d/bgpd start
> bgpd(failed)

You forgot to run sysmerge. The rc scripts changed on what they pgrep to
see if the parent process is running. Since the rc script is unable to
find the process it reports failed eventhough all is OK.
 
> shell# ps aux|grep bgp
> _bgpd11880  0.0  0.0  1220  1804 ??  Sp 7:46PM0:00.02 bgpd:
> session engine (bgpd)
> _bgpd11350  0.0  0.0   920  1816 ??  Sp 7:46PM0:00.02 bgpd: route
> decision engine (bgpd)
> root 18325  0.0  0.0   864  1484 ??  Is 7:46PM0:00.01
> /usr/sbin/bgpd
> root 13125  0.0  0.0   176   356 p0  R+ 7:47PM0:00.00 grep bgp
> 
> 
> rcctl reports the same, but ???ps aux|grep bgp??? after looks even worse:
> 
> shell# rcctl restart bgpd
> bgpd(failed)
> 
> shell]# ps aux|grep bgp
> root 18325  0.0  0.0   864  1484 ??  Ss 7:46PM0:00.01
> /usr/sbin/bgpd
> _bgpd11880  0.8  0.1  2120  3244 ??  Sp 7:46PM0:00.66 bgpd:
> session engine (bgpd)
> _bgpd11350  0.0  0.0   952  1864 ??  Sp 7:46PM0:00.04 bgpd: route
> decision engine (bgpd)
> _bgpd 2567  0.7  0.1  2108  3404 ??  Sp 7:50PM0:00.62 bgpd:
> session engine (bgpd)
> _bgpd 4216  0.0  0.0   944  1840 ??  Sp 7:50PM0:00.01 bgpd: route
> decision engine (bgpd)
> root 13197  0.0  0.0   864  1484 ??  Ss 7:50PM0:00.01
> /usr/sbin/bgpd
> root  3906  0.0  0.0   292   512 p0  R+ 7:50PM0:00.00 grep bgp
> 

-- 
:wq Claudio

Re: 64 Queue Size, ARC routing, MP Networking, OpenBSD 5.9

[Stuart Henderson]

On 2016-02-07, Andy Lemin  wrote:
> Hi everyone,
>
> Just a couple very quick 5.9 questions;
>
>
> 1) Will 5.9 have a 64bit integer for the queue sizes, or are we still
> limited to ~4294M?

There haven't been any changes in that area.

> 2) When 5.9 comes out, will the new ARC routing table be enabled by
> default? If not can we turn it on without building from source?

ART not ARC. It's not enabled by default, you'll need to build
a new kernel to use it.

> 3) Does anyone know which parts of the Network stack will have MP support
> in 5.9?
> MP NIC Interrupts, yes/no?
> MP Network Stack, yes/no?
> MP Queueing, yes/no?
> MP PF, yes/no?
> HW Offloading and other general MP NIC driver stuff (em(), ix()) yes/no?
> Any other important parts needing MP?
>
>
> It is difficult to understand where we are currently. I know we are
> excitingly close with the MP work (and thank you again for such amazing
> work!), but we need to know for business decision reasons because simply we
> are growing faster than OpenBSD's performance is, and we also have a new
> VP.
>
> So I'm deeply saddened to realise that if the MP networking commits do not
> make it in to get us above 4Gbps in 5.9 we will have to say goodbye to
> OpenBSD for good (I really seriously don't want too because OpenBSD is
> better than *any* firewalls out there, but we are still a business and need
> to make money, and we need more than 2-4Gbps).
>
> NB; 4Gbps is all we've managed on our current hardware class and 2Gbps with
> PF enabled.
>
> Hardware:
> Supermicro X9DRW-iF
> 4x 1866 DDR3 DIMMS
> Cpu0/1: Intel(R) Xeon(R) CPU E5-2637 v2 @ 3.50GHz, Turbo+ enabled = 3600.01
> MHz (Virtualisation, Hyperthreading and extra Cores disabled)
> Intel 82599 10Gbps NICs
>
>
> We need to be getting closer to 8Gbps with PF enabled by this summer, or
> I've been told to replace OpenBSD with something faster.. FreeBSD can max
> the 10G ports, but FBSD is not good enough for us in many other ways, so
> would mean a move to commercial firewalls (Hurghh).
>
> I REALLY don't want to have to walk away from OpenBSD in my current job :_(
>
> Cheers, Andy.
>
> Thanks everyone, and good luck on these big changes..
>
>

Good luck with the commercial firewalls!

Re: 64 Queue Size, ARC routing, MP Networking, OpenBSD 5.9

[Christian Weisgerber]

On 2016-02-07, Andy Lemin  wrote:

> So I'm deeply saddened to realise that if the MP networking commits do not
> make it in to get us above 4Gbps in 5.9 we will have to say goodbye to
> OpenBSD for good

Just install a snapshot and test how it performs in your environment.
There will not be any significant changes in that area between now
and 5.9.  If it doesn't work out for you, too bad.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: GCC 4.2.1 on 5.8 stable: printf enables merging linked lists?

[Philip Guenther]

On Sun, Feb 7, 2016 at 12:04 PM, Pavan Maddamsetti
 wrote:
> On Sun, Feb 7, 2016 at 3:01 PM, Pavan Maddamsetti
>  wrote:
>> Thanks for responding. At first, listp points at an uninitialized
>> pointer-sized chunk of stack memory. Depending on the contents of ap
>> and bp, it gets overwritten with either of those two pointers.


That may be what you want it to do, but that's not what the code does.
I suggest you compile with -g and walk through it under the debugger,
printing the value of listp before and after you think it's being
changed.

It may be easier to see if you initialize listp to NULL.  You say it's
set before being accessed, so initializing it should have no effect...

Philip Guenther

Re: GCC 4.2.1 on 5.8 stable: printf enables merging linked lists?

[Stuart Henderson]

On 2016-02-07, Pavan Maddamsetti  wrote:
> Thanks for helping me with this issue, Mr. Guenther. I'm not familiar
> with gdb so it may take some time for me to learn it...however, please
> note that
>
> cc -O0 wtf.c -o wtf
>
> produces a working binary where
>
> cc -O2 wtf.c -o wtf
>
> causes the program to get stuck. So I have reason to believe GCC's
> optimizations are faulty.

That is *sometimes* the case, but it usually just means that the program
relies on something which is undefined behaviour; compilers are allowed
to interpret this how they want, and often do, especially where the
optimizer is concerned.

Quick intro: compile with -g then "gdb ./wtf", "break main" (or some
other function), "run", step with 'n', use 'print' to examine variables.
Examine online help / docs for more.

> I did attempt to initialize listp as NULL. However, the code then
> dereferences listp with (*last)->next causing a segmentation fault.

Didn't you say that it gets overwritten with either ap or bp though?
If that's the case, how is it dereferencing a null pointer?

Re: GCC 4.2.1 on 5.8 stable: printf enables merging linked lists?

[Pavan Maddamsetti]

I am using amd64. Just to make sure I am describing this behavior
correctly, when there is no print statement at the line in question,
the program hangs indefinitely.

Otherwise the merge routine appears to work.

On Sun, Feb 7, 2016 at 2:57 PM, Pavan Maddamsetti
 wrote:
> amd64
>
> On Sun, Feb 7, 2016 at 2:53 PM, Daniel Dickman  wrote:
>> i cannot confirm on i386. what platform are you on?
>>
>> On Sun, Feb 7, 2016 at 2:36 PM, Pavan Maddamsetti
>>  wrote:
>>> /*
>>>  * Here 's the code. Try commenting out the line that says "WTF mate!"
>>>  * On my machine, the loop never returns. Somehow printf makes it work.
>>>  * Compiler bug or not? Please compile and confirm.
>>>  */
>>>
>>> #include 
>>> #include 
>>>
>>> typedef struct List List;
>>> struct List {
>>> int data;
>>> List *next;
>>> };
>>>
>>> List *new(int);
>>> List *add(List *, List *);
>>> List *merge(List *, List *);
>>>
>>> int
>>> main(void)
>>> {
>>> List *a, *b, *t, *p;
>>> a = b = t = p = NULL;
>>>
>>> int i;
>>> for (i = 0; i < 10; i += 2)
>>> a = add(a, new(i));
>>> for (i = 1; i < 10; i += 2)
>>> b = add(b, new(i));
>>>
>>> printf("Printing a...\n");
>>> for (t = a; t != NULL; t = t->next)
>>> printf("%d ", t->data);
>>> printf("\n");
>>>
>>> printf("Printing b...\n");
>>> for (t = b; t != NULL; t = t->next)
>>> printf("%d ", t->data);
>>> printf("\n");
>>>
>>> printf("Merging a and b...");
>>> p = merge(a, b);
>>> printf("done.\n");
>>>
>>> printf("Printing...\n");
>>> for (t = p; t != NULL; t = t->next)
>>> printf("%d ", t->data);
>>> printf("\n");
>>>
>>> exit(0);
>>> }
>>>
>>> List *
>>> new(int data)
>>> {
>>> List *newp;
>>> newp = malloc(sizeof(List));
>>> newp->data = data;
>>> newp->next = NULL;
>>> return newp;
>>> }
>>>
>>> List *
>>> add(List *listp, List *newp)
>>> {
>>> List *p;
>>>
>>> if (listp == NULL)
>>> return newp;
>>> for (p = listp; p->next != NULL; p = p->next)
>>> ;
>>> p->next = newp;
>>> return listp;
>>> }
>>>
>>> List *
>>> merge(List *ap, List *bp)
>>> {
>>> List *listp;
>>> List **last;
>>> last = 
>>>
>>> for (;;) {
>>> if (ap == NULL) {
>>> (*last)->next = bp;
>>> break;
>>> } else if (bp == NULL) {
>>> (*last)->next = ap;
>>> break;
>>> }
>>> printf("\nWTF mate!\n"); /* problem here */
>>> if (ap->data < bp->data) {
>>> (*last)->next = ap;
>>> ap = ap->next;
>>> } else {
>>> (*last)->next = bp;
>>> bp = bp->next;
>>> }
>>> last = &((*last)->next);
>>> }
>>> return listp->next;
>>> }

Re: GCC 4.2.1 on 5.8 stable: printf enables merging linked lists?

[Pavan Maddamsetti]

Also I have described it incorrectly. It is supposed to point to a
List sized chunk of memory. I am a newbie C programmer, please be
patient.

On Sun, Feb 7, 2016 at 3:04 PM, Pavan Maddamsetti
 wrote:
> Excuse me, here is the "reply all"
>
> On Sun, Feb 7, 2016 at 3:01 PM, Pavan Maddamsetti
>  wrote:
>> Thanks for responding. At first, listp points at an uninitialized
>> pointer-sized chunk of stack memory. Depending on the contents of ap
>> and bp, it gets overwritten with either of those two pointers.
>>
>> On Sun, Feb 7, 2016 at 2:56 PM, Philip Guenther  wrote:
>>> On Sun, Feb 7, 2016 at 11:36 AM, Pavan Maddamsetti
>>>  wrote:
 /*
  * Here 's the code. Try commenting out the line that says "WTF mate!"
  * On my machine, the loop never returns. Somehow printf makes it work.
  * Compiler bug or not? Please compile and confirm.
>>>
>>> Compiler bug should always be the *last* thing you conclude, as it
>>> means you've given up on looking for the bug in your own code.
>>>
>>>
 List *
 merge(List *ap, List *bp)
 {
 List *listp;
 List **last;
 last = 

 for (;;) {
 if (ap == NULL) {
 (*last)->next = bp;
>>>
>>> Where does listp point?
>>>
>>>
>>> Philip Guenther

Re: GCC 4.2.1 on 5.8 stable: printf enables merging linked lists?

[Pavan Maddamsetti]

Excuse me, here is the "reply all"

On Sun, Feb 7, 2016 at 3:01 PM, Pavan Maddamsetti
 wrote:
> Thanks for responding. At first, listp points at an uninitialized
> pointer-sized chunk of stack memory. Depending on the contents of ap
> and bp, it gets overwritten with either of those two pointers.
>
> On Sun, Feb 7, 2016 at 2:56 PM, Philip Guenther  wrote:
>> On Sun, Feb 7, 2016 at 11:36 AM, Pavan Maddamsetti
>>  wrote:
>>> /*
>>>  * Here 's the code. Try commenting out the line that says "WTF mate!"
>>>  * On my machine, the loop never returns. Somehow printf makes it work.
>>>  * Compiler bug or not? Please compile and confirm.
>>
>> Compiler bug should always be the *last* thing you conclude, as it
>> means you've given up on looking for the bug in your own code.
>>
>>
>>> List *
>>> merge(List *ap, List *bp)
>>> {
>>> List *listp;
>>> List **last;
>>> last = 
>>>
>>> for (;;) {
>>> if (ap == NULL) {
>>> (*last)->next = bp;
>>
>> Where does listp point?
>>
>>
>> Philip Guenther

Re: GCC 4.2.1 on 5.8 stable: printf enables merging linked lists?

[Philip Guenther]

On Sun, Feb 7, 2016 at 11:36 AM, Pavan Maddamsetti
 wrote:
> /*
>  * Here 's the code. Try commenting out the line that says "WTF mate!"
>  * On my machine, the loop never returns. Somehow printf makes it work.
>  * Compiler bug or not? Please compile and confirm.

Compiler bug should always be the *last* thing you conclude, as it
means you've given up on looking for the bug in your own code.


> List *
> merge(List *ap, List *bp)
> {
> List *listp;
> List **last;
> last = 
>
> for (;;) {
> if (ap == NULL) {
> (*last)->next = bp;

Where does listp point?


Philip Guenther

64 Queue Size, ARC routing, MP Networking, OpenBSD 5.9

[Andy Lemin]

Hi everyone,

Just a couple very quick 5.9 questions;


1) Will 5.9 have a 64bit integer for the queue sizes, or are we still
limited to ~4294M?

2) When 5.9 comes out, will the new ARC routing table be enabled by
default? If not can we turn it on without building from source?

3) Does anyone know which parts of the Network stack will have MP support
in 5.9?
MP NIC Interrupts, yes/no?
MP Network Stack, yes/no?
MP Queueing, yes/no?
MP PF, yes/no?
HW Offloading and other general MP NIC driver stuff (em(), ix()) yes/no?
Any other important parts needing MP?


It is difficult to understand where we are currently. I know we are
excitingly close with the MP work (and thank you again for such amazing
work!), but we need to know for business decision reasons because simply we
are growing faster than OpenBSD's performance is, and we also have a new
VP.

So I'm deeply saddened to realise that if the MP networking commits do not
make it in to get us above 4Gbps in 5.9 we will have to say goodbye to
OpenBSD for good (I really seriously don't want too because OpenBSD is
better than *any* firewalls out there, but we are still a business and need
to make money, and we need more than 2-4Gbps).

NB; 4Gbps is all we've managed on our current hardware class and 2Gbps with
PF enabled.

Hardware:
Supermicro X9DRW-iF
4x 1866 DDR3 DIMMS
Cpu0/1: Intel(R) Xeon(R) CPU E5-2637 v2 @ 3.50GHz, Turbo+ enabled = 3600.01
MHz (Virtualisation, Hyperthreading and extra Cores disabled)
Intel 82599 10Gbps NICs


We need to be getting closer to 8Gbps with PF enabled by this summer, or
I've been told to replace OpenBSD with something faster.. FreeBSD can max
the 10G ports, but FBSD is not good enough for us in many other ways, so
would mean a move to commercial firewalls (Hurghh).

I REALLY don't want to have to walk away from OpenBSD in my current job :_(

Cheers, Andy.

Thanks everyone, and good luck on these big changes..

Re: bgpd in snapshot from 4 feb.

[Stuart Henderson]

On 2016-02-07, mxb  wrote:
> Hey,
> bgpd from snap of 4 feb. fails to start (according to rc):

Oops, I forgot to commit the rc.d script for this one. Remove the pexp line
for now, it will be fixed in the next snap.

Re: GCC 4.2.1 on 5.8 stable: printf enables merging linked lists?

[Pavan Maddamsetti]

Thanks for helping me with this issue, Mr. Guenther. I'm not familiar
with gdb so it may take some time for me to learn it...however, please
note that

cc -O0 wtf.c -o wtf

produces a working binary where

cc -O2 wtf.c -o wtf

causes the program to get stuck. So I have reason to believe GCC's
optimizations are faulty.

I did attempt to initialize listp as NULL. However, the code then
dereferences listp with (*last)->next causing a segmentation fault.

On Sun, Feb 7, 2016 at 3:41 PM, Philip Guenther  wrote:
> On Sun, Feb 7, 2016 at 12:04 PM, Pavan Maddamsetti
>  wrote:
>> On Sun, Feb 7, 2016 at 3:01 PM, Pavan Maddamsetti
>>  wrote:
>>> Thanks for responding. At first, listp points at an uninitialized
>>> pointer-sized chunk of stack memory. Depending on the contents of ap
>>> and bp, it gets overwritten with either of those two pointers.
>
>
> That may be what you want it to do, but that's not what the code does.
> I suggest you compile with -g and walk through it under the debugger,
> printing the value of listp before and after you think it's being
> changed.
>
> It may be easier to see if you initialize listp to NULL.  You say it's
> set before being accessed, so initializing it should have no effect...
>
> Philip Guenther

Re: bgpd in snapshot from 4 feb.

[Antoine Jacoutot]

On Sun, Feb 07, 2016 at 10:01:40PM +0100, Claudio Jeker wrote:
> You forgot to run sysmerge. The rc scripts changed on what they pgrep to
> see if the parent process is running. Since the rc script is unable to
> find the process it reports failed eventhough all is OK.

rc.d scripts are part of base, not etc; so running sysmerge or not will make no 
difference.

-- 
Antoine

Re: Ntpd's confusing log messages

[chohag]

Christian Weisgerber writes:
> On 2016-02-06, Lampshade  wrote:
> 
> > Feb  6 17:57:25 host ntpd[7585]: peer 150.254.183.15 now valid
> > Feb  6 17:58:17 host ntpd[9279]: adjusting local clock by 9.096751s
> > Feb  6 18:02:02 host ntpd[9279]: adjusting local clock by 7.971861s
> 
> > I don't think that clock is adjusted "by" that values.
> 
> It is.

There is a difference between "how much the clock is adjusted by", which
is implied by "is adjusted by", and "how much the clock needs to be
adjusted by", which is what's being done.

The message is the best kind of correct but could be clearer by either
including the amount of adjustment occuring at the time the message is
logged or distinguishing between "the amount that the clock needs to be
adjusted" and "the amount that the clock is being adjusted by right
now", eg.

"adjusting local clock by ms out of s"

 - or -

"local clock s out of sync; skewed ms (forwards|backwards)"

Whether clarifying this message lies within the purview of openbsd ports
is another matter.

Matthew

bgpd in snapshot from 4 feb.

[mxb]

Hey,
bgpd from snap of 4 feb. fails to start (according to rc):

shell# /etc/rc.d/bgpd start
bgpd(failed)

shell# ps aux|grep bgp
_bgpd11880  0.0  0.0  1220  1804 ??  Sp 7:46PM0:00.02 bgpd:
session engine (bgpd)
_bgpd11350  0.0  0.0   920  1816 ??  Sp 7:46PM0:00.02 bgpd: route
decision engine (bgpd)
root 18325  0.0  0.0   864  1484 ??  Is 7:46PM0:00.01
/usr/sbin/bgpd
root 13125  0.0  0.0   176   356 p0  R+ 7:47PM0:00.00 grep bgp


rcctl reports the same, but ‘ps aux|grep bgp’ after looks even worse:

shell# rcctl restart bgpd
bgpd(failed)

shell]# ps aux|grep bgp
root 18325  0.0  0.0   864  1484 ??  Ss 7:46PM0:00.01
/usr/sbin/bgpd
_bgpd11880  0.8  0.1  2120  3244 ??  Sp 7:46PM0:00.66 bgpd:
session engine (bgpd)
_bgpd11350  0.0  0.0   952  1864 ??  Sp 7:46PM0:00.04 bgpd: route
decision engine (bgpd)
_bgpd 2567  0.7  0.1  2108  3404 ??  Sp 7:50PM0:00.62 bgpd:
session engine (bgpd)
_bgpd 4216  0.0  0.0   944  1840 ??  Sp 7:50PM0:00.01 bgpd: route
decision engine (bgpd)
root 13197  0.0  0.0   864  1484 ??  Ss 7:50PM0:00.01
/usr/sbin/bgpd
root  3906  0.0  0.0   292   512 p0  R+ 7:50PM0:00.00 grep bgp

Re: GCC 4.2.1 on 5.8 stable: printf enables merging linked lists?

[Pavan Maddamsetti]

Dude. That is super cool. I had been vaguely aware of gdb before but
never used it to examine variables or anything useful.

So I got a segfault after initializing listp as NULL, which appears to
be a macro for (void *) 0 from my system header files. My thought was
that this occurred because I first dereferenced last to yield listp,
and then used the arrow operator to dereference the member next. Isn't

listp->next

equivalent to

(*listp).next

? In any case, I have surely made a novice error. I will follow Philip
Guenther's advice and go to a C programming forum first before
disturbing this mailing list.

On Sun, Feb 7, 2016 at 5:31 PM, Stuart Henderson  wrote:
> On 2016-02-07, Pavan Maddamsetti  wrote:
>> Thanks for helping me with this issue, Mr. Guenther. I'm not familiar
>> with gdb so it may take some time for me to learn it...however, please
>> note that
>>
>> cc -O0 wtf.c -o wtf
>>
>> produces a working binary where
>>
>> cc -O2 wtf.c -o wtf
>>
>> causes the program to get stuck. So I have reason to believe GCC's
>> optimizations are faulty.
>
> That is *sometimes* the case, but it usually just means that the program
> relies on something which is undefined behaviour; compilers are allowed
> to interpret this how they want, and often do, especially where the
> optimizer is concerned.
>
> Quick intro: compile with -g then "gdb ./wtf", "break main" (or some
> other function), "run", step with 'n', use 'print' to examine variables.
> Examine online help / docs for more.
>
>> I did attempt to initialize listp as NULL. However, the code then
>> dereferences listp with (*last)->next causing a segmentation fault.
>
> Didn't you say that it gets overwritten with either ap or bp though?
> If that's the case, how is it dereferencing a null pointer?