gammu-smsd sends sms only on startup - raspberry-pi

I run gammu-smsd:
# gammu-smsd
Log filename is "/var/log/gammu-smsd.log"
next I send sms via gammu-smsd-inject:
# echo sms bla bla bla | gammu-smsd-inject TEXT 123456789
gammu-smsd-inject[2050]: Warning: No PIN code in /etc/gammu-smsdrc file
gammu-smsd-inject[2050]: Created outbox message OUTC20151124_121117_00_796996999_sms0.smsbackup
Written message with ID /var/spool/gammu/outbox/OUTC20151124_121117_00_796996999_sms0.smsbackup
and..... 1 minute, 5 minites, 15 minutes and nothing.So I interrupt gammu-smsd by ^\ and start it again:
# gammu-smsd
Log filename is "/var/log/gammu-smsd.log"
And now I have in /var/log/gammu-smsd.log:
Tue 2015/11/24 12:17:07 gammu-smsd[2074]: Warning: No PIN code in /etc/gammu-smsdrc file
Tue 2015/11/24 12:17:07 gammu-smsd[2074]: Created POSIX RW shared memory at 0xb6fcc000
Tue 2015/11/24 12:17:07 gammu-smsd[2074]: Starting phone communication...
Tue 2015/11/24 12:17:17 gammu-smsd[2074]: Read 1 messages
Tue 2015/11/24 12:17:18 gammu-smsd[2074]: Message without SMSC, assuming you want to use the one from phone
Tue 2015/11/24 12:17:19 gammu-smsd[2074]: Transmitted OUTC20151124_121117_00_123456789_sms0.smsbackup (total: 1) to 123456789, message reference 0x1b
Tue 2015/11/24 12:17:25 gammu-smsd[2074]: Read 1 messages
My configuration /etc/gammu-smsdrc:
# Configuration file for Gammu SMS Daemon
# Gammu library configuration, see gammurc(5)
[gammu]
port = /dev/huawei
model = at
connection = at19200
synchronizetime = yes
# SMSD configuration, see gammu-smsdrc(5)
[smsd]
service = files
logfile = /var/log/gammu-smsd.log
#debuglevel = 255
commtimeout = 10
sendtimeout = 20
deliveryreport = log
transmitformat = auto
# Paths where messages are stored
inboxpath = /var/spool/gammu/inbox/
outboxpath = /var/spool/gammu/outbox/
sentsmspath = /var/spool/gammu/sent/
errorsmspath = /var/spool/gammu/error/
So what am I doing wrong?
--- EDIT ---
I have removed gammu installed via apt-get, downloaded newest gammu from website wammu.eu and I compiled like in instruction. So now:
# gammu version
[Gammu version 1.36.6]
...
And
# gammu-detect
; Configuration file generated by gammu-detect.
; Please check The Gammu Manual for more information.
[gammu]
device = /dev/ttyUSB0
name = Phone on USB serial port HUAWEI_MOBILE HUAWEI_MOBILE
connection = at
[gammu1]
device = /dev/ttyUSB1
name = Phone on USB serial port HUAWEI_MOBILE HUAWEI_MOBILE
connection = at
opening socket: Nie ma takiego urządzenia
Where /dev/huawei is created by ln -s /dev/ttyUSB0
Now I typed gammu identify to check my device and after 1 hour I interrupted it because it waiting for something - i don't know for what.
Bellow is backtrac from gdb:
# gdb --args gammu --identify
GNU gdb (Raspbian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 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 "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from gammu...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/local/bin/gammu --identify
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
^C
Program received signal SIGINT, Interrupt.
0xb6d674ec in select () at ../sysdeps/unix/syscall-template.S:81
81 ../sysdeps/unix/syscall-template.S: Nie ma takiego pliku ani katalogu.
(gdb) bt
#0 0xb6d674ec in select () at ../sysdeps/unix/syscall-template.S:81
#1 0xb6f32968 in serial_read () from /usr/local/lib/libGammu.so.7
#2 0xb6e95c8c in GSM_ReadDevice () from /usr/local/lib/libGammu.so.7
#3 0xb6e95dcc in GSM_WaitForOnce () from /usr/local/lib/libGammu.so.7
#4 0xb6e95ef0 in GSM_WaitFor () from /usr/local/lib/libGammu.so.7
#5 0xb6edda2c in ATGEN_Initialise () from /usr/local/lib/libGammu.so.7
#6 0xb6e94f20 in GSM_TryGetModel () from /usr/local/lib/libGammu.so.7
#7 0xb6e95518 in GSM_InitConnection_Log () from /usr/local/lib/libGammu.so.7
#8 0x00000000 in ?? ()
(gdb)

According to this thread you need to use the /dev/serial/by-id/ path to the USB device.
e.g. port = /dev/serial/by-id/usb-Standard_USB_USB_2.0-if01
See http://comments.gmane.org/gmane.linux.drivers.gammu/9719

Related

Issue debugging a 32-bits assembly Hello world with GDB on a Raspberry Pi running a 64 bit version of Linux

I am trying to setup my Raspberry Pi so I can start learning ARM, and have issues debugging 32-bits ARM files. First, some informations maybe useful to my problem:
$ uname -a
Linux raspberrypi 5.15.32-v8+ #1538 SMP PREEMPT Thu Mar 31 19:40:39 BST 2022 aarch64 GNU/Linux
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
I can write a hello world program (in assembly) for ARM64, compile it using as and ld, then execute it and debug it with gdb without any issue. For 32 bits ARM, after installing the package binutils-arm-linux-gnueabihf, I can compile my files using arm-linux-gnueabihf-as/ld and execute them without issue. However, I have problems debugging them with gdb.
My version of gdb is :
$ gdb -v
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
and I am using the GEF extension. The file command for the 32-bits file gives:
$ file helloworld
helloworld: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped
After typing gdb helloworld, I can run it using the r command and it does print Hello world, but I can't debug it step by step: setting a breakpoint to the entry point (in my case, 0x10074 - obtained with info file -, which does not seem standard) makes the program run indefinitely, as if it was in an infinite loop, and stopping it with CTRL+C gives me:
$sp : 0x798fdfb4
$lr : 0xc6ac9670
$pc : 0x20
$cpsr: [negative ZERO CARRY OVERFLOW INTERRUPT FAST thumb]
────────────────────────────────────────────────────────────────────────────────────────── stack ────
[!] Unmapped address: '0x55798fdfb4'
─────────────────────────────────────────────────────────────────────────────────── code:arm:ARM ────
[!] Cannot disassemble from $PC
[!] Cannot access memory at address 0x20
──────────────────────────────────────────────────────────────────────────────────────── threads ────
[#0] Id 1, Name: "helloworld", stopped 0x20 in ?? (), reason: SIGINT
I am not sure what is going on. The address in Unmapped address: '0x55798fdfb4' looks like a standard .text address under PIE + ASLR, but I don't know why there would be mapping issues. How could I fix this ?
This answer is more an answer to the question: "How can I learn 32 bit assembly language on my raspberry Pi" than a direct answer to yours:
If your goal is to learn Aarch32 T32 or A32 assembly language on your raspberry Pi, I would strongly suggest to do so on a 32 bit distribution - I am not sure at this stage that you can debug a user mode Aarch32 program on an Aarch64 Linux system using an Aarch64 multiarch GDB or an Aarch32 version of GDB, my own attempts having been unsuccessful, and having not found to this day examples of how exactly to do this.
Another pro of this approach is that you will be able to concentrate on learning 32 bit Arm, and not asking yourself if your programs are not working because of a bug, or because off a potential problem/bug in the tools you are running on your Aarch64 system - my two cents.
If you have a spare 8GiB micro-SD card, you can install a 32 bit version of Ubuntu Server 22.04 from here.
One installed, here is what I am getting on my system:
cat /sys/firmware/devicetree/base/model
Raspberry Pi 3 Model B Rev 1.2
uname -a
Linux ubuntu 5.15.0-1005-raspi #5-Ubuntu SMP PREEMPT Mon Apr 4 12:25:49 UTC 2022 armv7l armv7l armv7l GNU/Linux
Install gcc and gdb:
sudo-apt -get install gcc gdb
Create hello-world.s, adapted from this example:
.arch armv7a
.file "hello-world.s"
.text
.global main
.syntax unified
.thumb
.thumb_func
.type main, %function
main:
mov r0, #1 # 1 = stdout
ldr r1, =hello_world # str pointer
mov r2, #13 # str len
mov r7, #4 # linux write syscall
svc 0 # software interrupt call write
exit:
mov r0, #0 # return code
mov r7, #1 # linux exit syscall
svc 0 # software interrupt call exit
.data
hello_world:
.ascii "Hello World!\n"
.end
as -g -o hello-world.o hello-world.s
gcc -g -o hello-world hello-world.o
./hello-world
Hello World!
GDB debug session:
gdb ./hello-world
GNU gdb (Ubuntu 12.0.90-0ubuntu1) 12.0.90
Copyright (C) 2022 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 "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./hello-world...
(gdb) b main
Breakpoint 1 at 0x4e0: file hello-world.s, line 10.
(gdb) run
Starting program: /home/ubuntu/hello-world
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Breakpoint 1, main () at hello-world.s:10
10 mov r0, #1 # 1 = stdout
(gdb) step
11 ldr r1, =hello_world # str pointer
(gdb)
12 mov r2, #13 # str len
(gdb)
13 mov r7, #4 # linux write syscall
(gdb)
14 svc 0 # software interrupt call write
(gdb)
Hello World!
exit () at hello-world.s:16
16 mov r0, #0 # return code
(gdb)
17 mov r7, #1 # linux exit syscall
(gdb)
18 svc 0 # software interrupt call exit
(gdb)
[Inferior 1 (process 3043) exited normally]
(gdb) quit

Analyzing a .dmp crash file?

I tried traditional ways and answers to analyze my .DMP files. WinDbg doesn`t take it, it outputs:
Could not find the C:\program files\softwaredir\dumps\dumpname_0313.rsa.dmp
File, Win32 error 0n87
It's an Multi Theft Auto: San Andreas crash dump. .rsa.dmp
Why doesn`t WinDbg take it, does it have to do with a certain dump type?
If anyone would want to try opening, here is the dumpfile with the issue
I would like to know if you have the solution to solve the opening problem/or any other tool to open the dump.
But I really need the exception that caused the crash, so either I'll need advise on how to open it or if I can fix it.
For case 2 (can't solve it for me here) the crash memory locations are:
Version 1.3.5-release 6078.0.000
Time Tue Jan 21 03:13:18 2014
Module C:\Program Files (x86)\MTA San Andreas 1.3\mods\deathmatch\client.dll
Code 0 x C0000005
Offset 0 x 0009E796
EAX 00000000 EBX 30994AB0 ECX 21E82218 EDX 0028F71C ESI 3098E520
EDI 6FBBCCC9 EBP 0028F7BC ESP 0028F6F4 EIP 1B00E796 FLG 00210246
CS 0023 DS 002B SS 002B ES 002B FS 0053 GS 002B
This is what I did to generate and analyze a dump file:
Downloaded ProcDump (a free Sysinternals tool)
Created a folder c:\dumps
Added ProcDump to PATH
Entered procdump -ma -i c:\dumps into command prompt to start the JustInTime debugger
Opened the dump file in visual studio
Using this method we were able to resolve a difficult bug and determine what exception was causing my machine to crash.

Sometimes Windows Crash while LabVIEW operator Advantech PCI-1716 card

The system include 2 Advantech PCI-1716 card:http://www.advantech.com/products/PCI-1716/mod_86EC4C4D-F497-45C5-81DA-B8600C0EB36F.aspx
I write a program with NI LabVIEW 7.1.
The LabVIEW program can control the two PCI 1716 card.
It work very good.
But about a year later, The computer crashed and sometimes auto restart.
Nobody change the software and hardware.
I used WinDbg to analysis the Windows crash dump file and I think I find something abnormal.
For the WinDbg result, I think maybe the PCI-1716 driver was broken so I re-installed it.
But the problem also happen.
And I also re-installed my windows xp.
The also problem happen again.
I don't know how.
Maybe the PCI 1716 hardware broken.
But how to find which one, there are two PCI 1716 card.
The WinDbg result is:
Loading Dump File [F:\WinDBG\Mini012313-01.dmp] Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: srv*C:\Documents and Settings\cky\symbols*http://msdl.microsoft.com/download/symbols Executable search path is: Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible Product: WinNt, suite: TerminalServer SingleUserTS Built by: 2600.xpsp_sp2_rtm.040803-2158 Kernel base = 0x804d8000 PsLoadedModuleList = 0x8055d700 Debug session time: Wed Jan 23 23:09:23.250 2013 (GMT+8) System Uptime: 0 days 23:47:48.802 Loading Kernel Symbols ....................................................................................................... Loading User Symbols Loading unloaded module list ....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 1000000A, {ffdf, 2, 1, 806e5a8e}
Unable to load image ADS1716S.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ADS1716S.sys
*** ERROR: Module load completed but symbols could not be loaded for ADS1716S.sys Probably caused by : ADS1716S.sys ( ADS1716S+f08 )
Followup: MachineOwner
---------
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
IRQL_NOT_LESS_OR_EQUAL (a) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If a kernel debugger is available get the stack backtrace. Arguments: Arg1: 0000ffdf, memory referenced Arg2: 00000002, IRQL Arg3: 00000001, bitfield : bit 0 : value 0 = read operation, 1 = write operation bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status) Arg4: 806e5a8e, address which referenced memory
Debugging Details:
------------------
WRITE_ADDRESS: 0000ffdf
CURRENT_IRQL: 2
FAULTING_IP: hal!KeAcquireQueuedSpinLock+42 806e5a8e 8902 mov dword ptr [edx],eax
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xA
PROCESS_NAME: LabVIEW.exe
LAST_CONTROL_TRANSFER: from 804efbb0 to 806e5a8e
STACK_TEXT: aa286c00 804efbb0 aa286c20 804f0de4 aa286c1c hal!KeAcquireQueuedSpinLock+0x42 aa286c08 804f0de4 aa286c1c 8602dc38 806e53b8 nt!IoAcquireCancelSpinLock+0xe aa286c20 804f104a 8602dc38 00000001 aa286c58 nt!IopStartNextPacket+0x18 aa286c30 f788ef08 8602dc38 00000001 85eb0230 nt!IoStartNextPacket+0x38 WARNING: Stack unwind information not available. Following frames may be wrong. aa286c58 80575529 85eb0230 86090da0 85f32448 ADS1716S+0xf08 aa286c80 805d1cb9 85f32448 85f32448 85f32690 nt!IoCancelThreadIo+0x33 aa286d08 805d209a 00000001 85f32448 00000000 nt!PspExitThread+0x403 aa286d28 805d2275 85f32448 00000001 aa286d64 nt!PspTerminateThreadByPointer+0x52 aa286d54 8054160c 00000000 00000001 0012e810 nt!NtTerminateProcess+0x105 aa286d54 7c92eb94 00000000 00000001 0012e810 nt!KiFastCallEntry+0xfc 0012e810 00000000 00000000 00000000 00000000 0x7c92eb94
STACK_COMMAND: kb
FOLLOWUP_IP: ADS1716S+f08 f788ef08 ?? ???
SYMBOL_STACK_INDEX: 4
SYMBOL_NAME: ADS1716S+f08
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: ADS1716S
IMAGE_NAME: ADS1716S.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 45b96de9
FAILURE_BUCKET_ID: 0xA_W_ADS1716S+f08
BUCKET_ID: 0xA_W_ADS1716S+f08
Followup: MachineOwner
---------
0: kd> lmvm ADS1716S start end module name f788e000 f7893ac0 ADS1716S T (no symbols)
Loaded symbol image file: ADS1716S.sys
Image path: ADS1716S.sys
Image name: ADS1716S.sys
Timestamp: Fri Jan 26 10:56:41 2007 (45B96DE9)
CheckSum: 00010C75
ImageSize: 00005AC0
Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0
I'd run Memtest86+ just to see if you have any bad RAM.
Following that maybe you can pull 1 card out and write a simple script to do some I/O (similar to what you're doing normally maybe). If it takes a while you could put it into a loop and run it for a while and see if you can force a crash. You could repeat the test on each card to see if you have any issues with just one of the cards.
Does the crash happen often or rarely?

Apache children hanging / mod perl

The apache children on my server (ubuntu 12.04 upgraded from 11.10, apache 2.2.22, perl 5.14.2, mod_perl 2.0.5) are hanging.
I tried to catch signals usr2, and alarm but without success (when using sleep for testing, it works like excpected but when the programm hangs by itself no output is given)
sub handler : method{
my $mask = POSIX::SigSet->new(&POSIX::SIGUSR2, &POSIX::SIGALRM);
my $oldaction_usr2 = POSIX::SigAction->new();
my $oldaction_alarm = POSIX::SigAction->new();
my $action = POSIX::SigAction->new(sub {
Carp::confess("hm caught SIGUSR2 or ALARM DEAD LOCK YOU can run but not hide!");
},$mask,&POSIX::SA_NODEFER);
POSIX::sigaction(&POSIX::SIGUSR2,$action, $oldaction_usr2);
POSIX::sigaction(&POSIX::SIGALRM,$action, $oldaction_alarm);
alarm(30); #max 30 seconds per request
So I used Apache status to get the pid of the child which is hanging (cpu time is not increasing but only SS (Seconds since beginning of most recent request).
Then I attach gdb with the pid to get an backtrace:
(gdb) bt
#0 0x00007fc4610fb606 in myck_entersub (my_perl=0x7fc47f7f63e0, op=0x7fc484b40910) at lib/Params/Classify.xs:682
#1 0x00007fc477a67abd in Perl_convert () from /usr/lib/libperl.so.5.14
#2 0x00007fc477a6f769 in Perl_utilize () from /usr/lib/libperl.so.5.14
#3 0x00007fc477a9daef in Perl_yyparse () from /usr/lib/libperl.so.5.14
#4 0x00007fc477b1635d in ?? () from /usr/lib/libperl.so.5.14
the problem is I have no idea how to fix this or what this means.
On modper 1 gude I found:
% gdb httpd <pid of spinning process>
(gdb) where
(gdb) source mod_perl-x.xx/.gdbinit
(gdb) curinfo
but I don't know where .gdbinit is located or which package I need to install
or do I need to make this file by my self from source (maybe with Devel::DebugInit::GDB) ?
The problem may be "Params::Classify," which is not thread-safe. See:
https://bugs.launchpad.net/ubuntu/+source/libmodule-runtime-perl/+bug/991650
mod_perl script going in to a tight loop during 'use' processing
http://www.perlmonks.org/?node_id=886909
The author of Params::Classify acknowledged the problem in November 2011 but has not released a fix.

iphone development: Too many log on gdb

When i debug a programmer, I found too many lines useless info which appear in GDB. this kind of infomation may come from iphone framework. it is not logged by my code. the info like this
Node 48 TrialMT(102,102,101,101)
Node 58 TrialMT(102,102,101,101)
Node 69 TrialMT(102,102,101,101)
Node 72 TrialMT(102,102,101,101)
Just too much. so i can not find my log.
I want to known is there a way i can export GDB log to a file, so i can find my log info in the file later on.
thanks
In Xcode you can type GDB commands in the debugger console. There you can reset the stdout and stderr file descriptors to your preferred log file like this
(gdb) call (void)close(1)
(gdb) call (void)close(2)
(gdb) call (int)open("/tmp/out.log", 0x201, 0644)
$1 = 1
(gdb) call (int)dup(1)
$2 = 2
(gdb) continue