Bug 6797

If you are getting a seg fault when rp3 is first setting up your
connection, even with the recent patch I have noticed that if there
are any ppp devices configured rp3-config will seg fault.  Before I
upgraded to 6.1 I had used the control-panel to setup my ppp device.
I just used it to remove the ppp device, and the seg fault no longer
occurs.

Do you have any /etc/sysconfig/network-scripts/ifcfg-* files
that have no DEVICE=<something> line in them?

------- Additional Comments From   11/09/99 05:39 -------
I have the same problem - updating a 6.0 system to 6.1 with
old ppp devices previously configured by linuxconf.  I seem to
be able to connect OK, but it takes 2 tries to do it, and rp3-config
segfaults immediately.  All ifcfg-pppX files have a "DEVICE=pppX"
entry in them, and I am using rp3-1.0.1.

Can you try
ftp://ftp.redhat.com/pub/rawhide/i386/RedHat/RPMS/rp3-1.0.2-1.i386.rpm
and see if it fixes the problem for you?

Tried rp3-1.0.2 with my old ifcfg-pppX files and /etc/ppp/pap-secrets put
back (I'd given up, moved my old ppp files, and recreated new accounts
with rp3).  rp3-config still seg-faults with those ifcfg-ppp and chat files,
and still seems to take 2 tries to set up the connection.

jmmartin: ppp-2.3.10-3 is what fixes the double-dial problem.
I'll also need a stack trace to deal with the rp3 segv.
  su
  gdb /usr/bin/rp3-config
  r
  bt
Thanks.

I'll me-too this one with some dump data; it still doesn't work with
rp3-1.0.2-1.i386.rpm :(

Let me first note that all my /etc/sysconfig/network-scripts/ifcfg-* files
have a DEVICE=<something> line in them (with in fact <something> equal to what
matches '*', which is empty in one case: file ifcfg- ).

This first dump was made with version rp3-1.0.1-1.i386.rpm

[root@Robinson /root]# gdb /usr/sbin/rp3-config
GNU gdb 4.18 etc.
(gdb) r
Starting program: /usr/sbin/rp3-config

Program received signal SIGSEGV, Segmentation fault.
strncmp (s1=0x808098c "ppp", s2=0x0, n=3) at ../sysdeps/generic/strncmp.c:65
65      ../sysdeps/generic/strncmp.c: No such file or directory.
Current language:  auto; currently c
(gdb) where
#0  strncmp (s1=0x808098c "ppp", s2=0x0, n=3)
    at ../sysdeps/generic/strncmp.c:65
#1  0x807b0df in interface_status_update (i=0x80cecc8) at interface.c:417
#2  0x807aea0 in interface_new (interfaceName=0x80ceaa5 "") at interface.c:324
#3  0x807aac6 in interface_list_generate () at interface.c:181
#4  0x8053b2d in load_accounts () at account.cc:417
#5  0x805ec5e in rp3_mainwin_new () at mainwin.cc:518
#6  0x80663f5 in main (argc=1, argv=0xbffffda4) at main.cc:149
(gdb)


And then I upgraded to the lastest and greatest version of rp3. It still
segfaults, but in a slightly different manner. I may add that there was a
noticeable delay (more than a second) between starting the program and the
segfault.

[root@Robinson /root]# rpm -q rp3
rp3-1.0.2-1
[root@Robinson /root]# gdb /usr/sbin/rp3-config
GNU gdb 4.18 etc.
(gdb) r
Starting program: /usr/sbin/rp3-config

Program received signal SIGSEGV, Segmentation fault.
chunk_free (ar_ptr=0x74, p=0x404ec0a8) at malloc.c:2985
2985	malloc.c: No such file or directory.
Current language:  auto; currently c
(gdb) where
#0  chunk_free (ar_ptr=0x74, p=0x404ec0a8) at malloc.c:2985
#1  0x40457d75 in __libc_free (mem=0x404ec0b0) at malloc.c:2959
#2  0x807a5b1 in svCloseFile (s=0x80cec00) at shvar.c:371
#3  0x807a851 in interface_shvarfiles_close (ifcfg=0x80cec00) at interface.c:86
#4  0x807afb0 in interface_free (i=0x80d2d40) at interface.c:371
#5  0x80541a8 in load_accounts () at account.cc:473
#6  0x805ec5e in rp3_mainwin_new () at mainwin.cc:518
#7  0x80663f5 in main (argc=1, argv=0xbffffda4) at main.cc:149
(gdb)

Could you both try the latest test release at:
ftp://people.redhat.com/johnsonm/rp3/rp3-1.0.3-1.i386.rpm
I'm 99.999% positive it will fix maavl's problem, and about
80% positive that it will solve haeri's.

It does indeed work for me now with rp3-1.0.3.

I'm not sure if this is the same bug I am experiencing because my symptoms are
slightly different.  usernet launches, but then randomly crashes after a while.
Here's what I get:

usernet: interface.c:499: interface_txrx_update: Assertion `f' failed.
Aborted                 (core dumped) usernet

gdb /usr/bin/usernet core
[...]

(gdb) bt
#0  0x404524e1 in __kill () from /lib/libc.so.6
#1  0x40452156 in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2  0x40453868 in abort () at ../sysdeps/generic/abort.c:88
#3  0x4044c3ce in __assert_fail (assertion=0x80553cf "f",
    file=0x8055139 "interface.c", line=499,
    function=0x80553a3 "interface_txrx_update") at assert.c:59
#4  0x8051603 in interface_txrx_update (i=0x8097a98) at interface.c:499
#5  0x804d927 in display_txrx_update (data=0x80b7940) at display.c:79
#6  0x4041fa04 in g_timeout_dispatch () from /usr/lib/libglib-1.2.so.0
#7  0x4041ebe6 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#8  0x4041f1a1 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#9  0x4041f341 in g_main_run () from /usr/lib/libglib-1.2.so.0
#10 0x40236339 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#11 0x804d82b in usernet_main (argc=1, argv=0xbffff924) at rp3.c:149
#12 0x804d877 in main (argc=1, argv=0xbffff924) at rp3.c:164
(gdb)

Oops, I forgot to mention.  The backtrace I posted was for rp3-1.0.3.  I was
getting the same symptoms with rp3-1.0.1 but didn't check the backtrace.

Have exactly the same problem (usernet crash after a few seconds), even after
upgrading to rp3-1.0.7-1:

** ERROR **: file interface.c: line 504 (interface_txrx_update): assertion
failed: (f)
aborting...

(gdb) bt
#0  0x4046d851 in __kill () from /lib/libc.so.6
#1  0x4046d4c6 in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2  0x4046ebd8 in abort () at ../sysdeps/generic/abort.c:88
#3  0x403b12a3 in g_logv () from /usr/lib/libglib-1.2.so.0
#4  0x403b1366 in g_log () from /usr/lib/libglib-1.2.so.0
#5  0x8051b7e in interface_txrx_update ()
#6  0x804d9cf in display_warning ()
#7  0x403afa04 in g_timeout_dispatch () from /usr/lib/libglib-1.2.so.0
#8  0x403aebe6 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#9  0x403af1a1 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#10 0x403af341 in g_main_run () from /usr/lib/libglib-1.2.so.0
#11 0x401c5339 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#12 0x804d8ac in _start ()
#13 0x804d901 in main ()
#14 0x4046752b in __libc_start_main (main=0x804d8c0 <main>, argc=1,
    argv=0xbffffb94, init=0x804c428 <_init>, fini=0x8054f4c <_fini>,
    rtld_fini=0x4000ac50 <_dl_fini>, stack_end=0xbffffb8c)
    at ../sysdeps/generic/libc-start.c:92
(gdb)

All ifcfg-* files in /etc/sysconfig/network-scripts have DEVICE= lines.  It may
not be significant, but I am using multiple IPs on one NIC, so I have an eth0 as
well as an eth0:0 (with corresponding scripts ifcfg-eth0 and ifcfg-eth0:0).

The error is a failure opening /proc/net/dev for reading.  Is your /proc
filesystem not mounted properly?  Is /proc/net/dev not there for some
reason?  Are you running the 2.2 kernel shipped with Red Hat Linux 6.1?

/proc is mounted, /proc/net/dev exists, and is world-readable (444).  I am
currently running kernel 2.2.13, but I booted into the 2.2.12smp kernel shipped
with Red Hat, and the same problem occurs.

I've been unable to reproduce the problem here, both with IP aliases and with
other accounts set up using netcfg.  Both roberts and vdhillon are hitting a
problem at the very same line of code, which *should* be impossible on a kernel
that has networking support compiled in.

The only thing I can think of that might shed light on this is whether or not
the C library is returning any useful information.  To find out, please run rp3
under gdb again, and when it hits the abort(), give gdb the command:
print strerror(errno)
which should print the text string associated with the most recent error.

OK, got this:

Program received signal SIGABRT, Aborted.
0x4046d851 in __kill () from /lib/libc.so.6
(gdb) print strerror(errno)
$1 = 0x4053445f "Too many open files"
(gdb)

That helps a lot.  I think you tickled a long-standing bug in the way rp3 would
read the counts for a network interface from the kernel:  it would open
/proc/net/dev, but unless the interface name was there it would never close it.
Do this several times a second, and boom! down it goes.

Please try the test release at
http://people.redhat.com/nalin/rp3-1.0.7-2.i386.rpm, which I'm fairly sure will
solve the problem.

It's been working perfectly for over an hour, so I think it's safe to assume
that did it.  Thank you!

In that case I'm putting 1.0.7-3 into our build tree for inclusion in the next
release.  Thanks for the help in tracking that down.

There are at least two people attached to this bug who haven't responded that
newer versions work for them, so I'm not going to close this bug right away.

This seems to have fixed it for me as well.  Thanks!

I have experienced the same problem as these guys and worked around it by using
only rp3 to configure my connections.  I am not going to get technical because
I'm not any where the level needed to help work out this one.  But I am hesitant
to add another ppp acct to my system for fear that it will mess up my existing
connection.

If you back up /etc/wvdial.conf and the contents of the /etc/ppp and
/etc/sysconfig/network-scripts directories (as well as the /etc/resolv.conf
and /etc/sysconfig/network files), you should be able to experiment with
your setup, and should things go wrong, restore your previous settings.

Closing because we don't ship rp3 anymore.