A few monthes I get segfault of smsd with fresh package build like this:

Mar 18 16:00:48 localhost kernel: [ 4372.756124] smsd[2204]: segfault at 640774 ip 00007fb76d2d1bcf sp 00007fff73ca70e0 error 4 in libc-2.15.so[7fb76d28a000+197000]

But there is old build about 1 year old which works fine. I think the problem is in new gcc and/or in new glibc. How can I figure out what is the problem ?

Today I tried to rebuild package smstools3 with nostrip and with gdb information compiled in (-g). smsd forks and I cannot see anything :-). I am not familiar with gdb. I tried do things described in https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces#Getting_the_trace


Operating system name and version: Archlinux
Version of smsd: 3.1.14
Smsd installed from: sources (AUR)
Name and model of a modem / phone: Huawei E150 for now
Interface: USB

Just now I remembered about strace. Here is its output:

nanosleep({0, 100000}, NULL) = 0 nanosleep({0, 100000}, NULL) = 0 nanosleep({0, 100000}, NULL) = 0 nanosleep({0, 100000}, NULL) = 0 nanosleep({0, 100000}, NULL) = 0 stat("/var/spool/sms/outgoing/send_XjmYT3", {st_mode=S_IFREG|0660, st_size=17, ...}) = 0 close(5) = 0 open("/tmp/smsd_checkhandler_1.ibULz4", O_RDWR|O_CREAT|O_EXCL, 0600) = 5 close(5) = 0 open("/tmp/smsd_checkhandler_2.mGtLn7", O_RDWR|O_CREAT|O_EXCL, 0600) = 5 close(5) = 0 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1196, ...}) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fe0b54b99d0) = 2370 wait4(2370, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 2370 --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=2370, si_status=0, si_utime=0, si_stime=0} (Child exited) --- stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1196, ...}) = 0 stat("/tmp/smsd_checkhandler_1.ibULz4", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 unlink("/tmp/smsd_checkhandler_1.ibULz4") = 0 stat("/tmp/smsd_checkhandler_2.mGtLn7", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 unlink("/tmp/smsd_checkhandler_2.mGtLn7") = 0 open("/var/spool/sms/outgoing/send_XjmYT3", O_RDONLY) = 5 fstat(5, {st_mode=S_IFREG|0644, st_size=17, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe0b54dd000 read(5, "To: s000105100\n\nq", 4096) = 17 close(5) = 0 munmap(0x7fe0b54dd000, 4096) = 0 open("/var/spool/sms/outgoing/send_XjmYT3", O_RDONLY) = 5 fstat(5, {st_mode=S_IFREG|0644, st_size=17, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe0b54dd000 read(5, "To: s000105100\n\nq", 4096) = 17 read(5, "", 36864) = 0 close(5) = 0 munmap(0x7fe0b54dd000, 4096) = 0 stat("/var/spool/sms/checked/send_XjmYT3.LOCK", 0x7fff544bb4f0) = -1 ENOENT (No such file or directory) open("/var/spool/sms/checked/send_XjmYT3.LOCK", O_WRONLY|O_CREAT|O_EXCL, 0644) = 5 --- {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x640774} (Segmentation fault) --- +++ killed by SIGSEGV +++

It happends when I run sendsms.

My current config is:

# grep -v "#" /etc/smsd.conf | grep -v "^$" devices = GSM1 logfile = /var/log/smsd/smsd.log loglevel = notice smart_logging = yes report = /var/spool/sms/report checkhandler = /usr/local/bin/checkhandler eventhandler = /usr/local/bin/smsevent date_filename = 2 date_filename_format = %Y%m%d_%H:%M:%S datetime_format = %Y-%m-%d %H:%M:%S [GSM1] init = AT+CPMS="ME","ME","ME" check_memory_method = 2 device = /dev/ttyUSB0 incoming = yes decode_unicode_text = yes pin = 1111

smsd compiled with iconv support to translate to UTF-8 on the fly. Exactly the same configuration works on openwrt with this modem. Patches for Makefile was taken from openwrt build discussed earlier on this forum. So again -- most likely this problem is in gcc or/and glibc which are very fresh in archlinux :-).

At first, as root:

1) echo /tmp/core.%p > /proc/sys/kernel/core_pattern
This is required because smsd changes its working directory to / on start and it won't be able to create core files unless it is run from the user root. The command above asks Linux kernel to create core files in the directory /tmp instead of the current working directory. Note that this parameter is global and will immediately affect all sessions.

Next, as a regular user:

2) Make sure that the maximum size of core files isn't zero using the command ulimit -c. If it is zero, set it to some reasonable value or unlimited with the command ulimit -c unlimited. Note that this parameter is local for current session. So...
3) Run smsd in the same session.
4) Reproduce segmentation fault.
5) Make sure that a core file has been created in /tmp.
6) Run gdb -c <core_file> <smsd_binary>
7) In GDB session, issue the command bt.

After that you should see a stack trace where the topmost function is the one where the segmentation fault happened.

Here is output of gdb:

tmp]# gdb -c /tmp/smsd.core.30777 /usr/bin/smsd GNU gdb (GDB) 7.4 Copyright (C) 2012 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-unknown-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/smsd...done. [New LWP 30777] warning: Can't read pathname for load map: Ошибка ввода/вывода. Core was generated by `smsd -t'. Program terminated with signal 11, Segmentation fault. #0 0x00007f05c42a0bcf in vfprintf () from /lib/libc.so.6 (gdb) (gdb) (gdb) bt #0 0x00007f05c42a0bcf in vfprintf () from /lib/libc.so.6 #1 0x00007f05c42cb2f2 in vsnprintf () from /lib/libc.so.6 #2 0x00007f05c42a7a62 in snprintf () from /lib/libc.so.6 #3 0x000000000041a573 in lockfile (filename=0x7fff262f5dd0 "/var/spool/sms/checked/send_bAjmEs") at locking.c:45 #4 0x0000000000416f14 in movefilewithdestlock_new ( filename=0x7fff26306fe0 "/var/spool/sms/outgoing/send_bAjmEs", directory=0x7fff26304e20 "/var/spool/sms/checked", keep_fname=1, store_original_fname=1, prefix=0x4370f3 "", newfilename=0x7fff26305fe0 "") at extras.c:233 #5 0x0000000000407ac3 in mainspooler () at smsd.c:1749 #6 0x0000000000416786 in main (argc=2, argv=0x7fff26308408) at smsd.c:6911 (gdb)

But I don't know what it means ...

I can confirm this. It seems that process_id == -1 at the moment of snprintf call...

You found a bug. The process_id is a modem index in modem processes and [always hardcoded ;-)] -1 in the main smsd process. Because DEVICE is actually devices[process_id], DEVICE must never be used unconditionally in shared code. Here is a quick patch.

diff -pruN smstools3.orig/src/locking.c smstools3/src/locking.c --- smstools3.orig/src/locking.c 2010-08-18 15:34:57.000000000 +0400 +++ smstools3/src/locking.c 2012-03-19 19:35:28.000000000 +0400 @@ -42,7 +42,8 @@ int lockfile( char* filename) lockfile=open(lockfilename,O_CREAT|O_EXCL|O_WRONLY,0644); if (lockfile>=0) { - snprintf(pid, sizeof(pid), "%i %s\n", (int)getpid(), DEVICE.name); + snprintf(pid, sizeof(pid), "%i %s\n", (int)getpid(), + (process_id == -1) ? "MAINPROCESS" : DEVICE.name); write(lockfile, pid, strlen(pid)); close(lockfile); sync();

Thanks for the patch. smsd does not segfault ... but it send one sms twice . Here is how I did:

1. Stop smsd
2. issue command "sendsms s000105100 q" (check balance on Megafon)
3. Start smsd
4. Receove 2 answers

Log tels:

2012-03-20 09:19:35,5, GSM1: CGSN: 354638045661500 2012-03-20 09:19:35,5, GSM1: IMSI: 250023006625076 #<-- start smsd 2012-03-20 09:19:53,5, smsd: Moved file /var/spool/sms/outgoing/send_BfUw4h to /var/spool/sms/checked # <-- one file but then 2 sms sent 2012-03-20 09:19:55,5, GSM1: SMS sent, Message_id: 139, To: s000105100, sending time 6 sec. 2012-03-20 09:19:58,5, GSM1: SMS sent, Message_id: 140, To: s000105100, sending time 3 sec. 2012-03-20 09:19:59,5, GSM1: SMS received, From: 000105100 2012-03-20 09:20:00,5, GSM1: SMS received, From: 000105100

Next sms is sent once :-). But old smsd does so. There is another bug or my own "feature" .

Today I'll test smsd better. Thanks.

I've the same problem as the original post, but thanks to the unterwulf patch everything is now working fine! (no twice sms, both recived and sent). IMHO the patch should be applied asap to the mainstream sources.

Meanwhile I've made a new spec file with the patch included for Fedora 17/18 (I'm using it). I'll try to submit them to the Fedora mantainers.

Many thanks,
Daniele

Thanks unterwulf and others. The patch is now applied.