# [solved] unrealircd segfaults - problem with libc-2.13.so?

## Jimini

Good morning and a happy new year to all of you.

I am using syslog-ng together with MySQL to fetch as many logs from my machines and collect them on a central logging machine, from where I read them with phpsyslogng. This works great so far.

Now I would like to instruct unrealircd not to keep its own logfiles, but to log everything to syslog-ng. The problem is, that unrealircd crashes, when an event on my IRC-server should be logged (for example when someone connects to the server). When the log is written to a file, everything works as expected.

The following error messages appeared in my syslog: 

 *Quote:*   

> N/A	Atlas	kern 	11:43:21 	kernel 	[4544266.476435] unrealircd[3425] general protection ip:7f8077bf26bf sp:7fff8889ffa0 error:0 in libc-2.13.so[7f8077bab000+182000]
> 
> N/A	Atlas	daemon 	11:43:20 	ircd 	UnrealIRCd started.
> 
> N/A	Atlas	daemon 	11:43:20 	ircd 	TIME SYNCH: IRCd clock succesfully synchronized to known good time source.
> ...

 

/etc/unrealircd/unrealircd.conf contains the following log-block:

```
log syslog {

        flags   {

                oper;

                kline;

                connects;

                server-connects;

                kills;

                errors;

                sadmin-commands;

                chg-commands;

                oper-override;

                spamfilter;

        };

};
```

"syslog" a the log target should work (have a look at http://forums.unrealircd.com/viewtopic.php?f=3&t=3349 ).

So I took a look at the log entries and re-emerged glibc. This had no effect at all.

This is the software I use:

unrealircd-3.2.9

syslog-ng-3-2-5

mysql-5.1.56

hardened-sources-3.0.4-r4

Any help would be really appreciated.

Best regards,

Jimini

----------

## Hu

What does the core file backtrace show?  The instruction is in libc, but that could just mean that unrealircd passed a bad pointer to a C library function, which the C library then dereferenced.

----------

## Jimini

Hu,

thank you for your answer. How do I get such a backtrace? I executed "gdb unrealircd", then "set logging file log.log", "set logging on" and "run". The gdb-shell only shew that the program was executed, but it didn't show a crash - although the server crashed in the background. Executing "bt" did not produce any helpful output at all. What am I doing wrong?

Best regards,

Jimini

----------

## Hu

If you try to debug the live program, you must make sure it does not get away from you.  Many programs designed to run as servers will automatically detach from their controlling terminal, which means gdb will think the program exited almost immediately.  Some daemons can be instructed not to move to the background, but this is program-specific.  The simplest solution, when other factors permit it, is to start the program uncontrolled, then attach gdb after it has entered daemon mode but before the crash happens.  In this case, that would mean you need to ensure no one tries to connect before you can get gdb attached.  You could also try instructing gdb to follow the child process at fork time, instead of staying with the parent.

----------

## Jimini

I got

 *Quote:*   

> Program received signal SIGSEGV, Segmentation fault.
> 
> 0x00007ffff695d6bf in vfprintf () from /lib64/libc.so.6

 

is this useful?

Best regards,

Jimini

----------

## Hu

On its own, no.  It confirms what I said could be a cause.  Someone misused a libc function, but the misuse was not caught until the libc function processed the bad input given to it from above.  We need the full backtrace to see who misused the libc function.

----------

## Jimini

Okay, I hope I got you right, here is the output:

 *Quote:*   

> (gdb) set args -F
> 
> (gdb) run
> 
> Starting program: /usr/bin/unrealircd -F
> ...

 

Then I connected to the server to produce an event, which should be logged.

 *Quote:*   

> Program received signal SIGSEGV, Segmentation fault.
> 
> 0x00007ffff723d5bf in vfprintf () from /lib64/libc.so.6
> 
> (gdb) bt full
> ...

 

Best regards,

Jimini

----------

## Hu

Yes, that is a backtrace.  It confirms that ircd_log is calling vsyslog, and that the resulting call faults.  We would need to examine the source code or see arguments and/or locals of ircd_log to know more.  You will need to rebuild with symbols before sys-devel/gdb can produce that information, though.

----------

## Jimini

I re-emerged unrealircd with FEATURES="nostrip" and got the following backtrace:

 *Quote:*   

> #0  0x00007ffff723d5bf in vfprintf () from /lib64/libc.so.6
> 
> No symbol table info available.
> 
> #1  0x00007ffff72e418f in __vfprintf_chk () from /lib64/libc.so.6
> ...

 

But it seems, as if the wanted information was missing, isn't it?

Best regards,

Jimini

----------

## Hu

Yes.  Did you follow all the steps in How to get meaningful backtraces in Gentoo?

----------

## Jimini

Fortunately, the problem could be solved. As you can read in my bug report ( http://bugs.unrealircd.org/view.php?id=4065 ), this bug should be fixed in the coming version of unrealircd.

Thank you very much for your effort, Hu!

Best regards,

Jimini

----------

