I have a problem when sending email from my Pi.
Recently I upgraded from jessie to stretch.
I want to send email with my Gmail account.
Installed ssmtp and mailutils.
sendmail can send emails.
But mail command always fails.
Mail -V also outputs segmentation fault.
I removed and purged mailutils but no change.
I catched core file and traced with gdb:
GNU gdb (Raspbian 7.7.1+dfsg-5+rpi1) 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 mail...(no debugging symbols found)...done.
warning: core file may not match specified executable file.
[New LWP 1620]
Dwarf Error: wrong version in compilation unit header (is 9661, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/80/04807a641723782e258f53fccb18b50d586940.debug]
Dwarf Error: wrong version in compilation unit header (is -17502, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/c3/90f5fdedf442d80621e7884a8b7661e9c8050f.debug]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Dwarf Error: wrong version in compilation unit header (is 30469, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/44/d64b51763b6272bc47bd01723b6bdf68f38a1c.debug]
Dwarf Error: wrong version in compilation unit header (is -25664, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/09/4b30e8c4ded4dca627b8adf5e6324125084005.debug]
Dwarf Error: wrong version in compilation unit header (is -27107, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/81/ceb8fe32848c140c8a3d1741242c6a996bdb0d.debug]
Dwarf Error: wrong version in compilation unit header (is -31079, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/e5/8601123ae22d2f43220005658f6cc8a9ad89f5.debug]
Core was generated by `mail -V'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x76277654 in nettle_yarrow256_update ()
from /usr/lib/arm-linux-gnueabihf/libnettle.so.6
(gdb)
#0 0x76277654 in nettle_yarrow256_update ()
from /usr/lib/arm-linux-gnueabihf/libnettle.so.6
(gdb) bt
Cannot access memory at address 0x0
#0 0x76277654 in nettle_yarrow256_update ()
from /usr/lib/arm-linux-gnueabihf/libnettle.so.6
#1 0x7610bf6c in ?? () from /usr/lib/arm-linux-gnueabihf/libgnutls-deb0.so.28
Cannot access memory at address 0x0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) frame 0
#0 0x76277654 in nettle_yarrow256_update ()
from /usr/lib/arm-linux-gnueabihf/libnettle.so.6
(gdb) frame 1
#1 0x7610bf6c in ?? () from /usr/lib/arm-linux-gnueabihf/libgnutls-deb0.so.28
(gdb)
:~ $ dpkg -l | grep mailutils
ii libmailutils5:armhf 1:3.1.1-1 armhf GNU Mail abstraction library
ii mailutils 1:3.1.1-1 armhf GNU mailutils utilities for handling mail
ii mailutils-common 1:3.1.1-1 all Common files for GNU mailutils
:~ $ dpkg -l | grep libnettle
ii libnettle4:armhf 2.7.1-5+deb8u2 armhf low level cryptographic library (symmetric and one-way
cryptos)
ii libnettle6:armhf 3.3-1+deb9u1 armhf low level cryptographic library (symmetric and one-way
cryptos)
: sudo apt-cache policy mailutils
mailutils:
installed version: 1:3.1.1-1
candidate: 1:3.1.1-1
version table:
*** 1:3.1.1-1 500
500 http://ftp.jaist.ac.jp/raspbian stretch/main armhf Packages
100 /var/lib/dpkg/status
The latest mailutils version is 3.14.
Related
Problem
I'm trying to debug this Rust program using rust-gdb, but I can't seem to get GDB to work properly:
/home/a/tmp/foo(HEAD)
09/19/2021 09:57:23.114 AM> rust-gdb -q target/debug/foo
Reading symbols from target/debug/foo...
(gdb) b hello
Breakpoint 1 at 0x7a44: file src/main.rs, line 2.
(gdb) run
Starting program: /home/a/tmp/foo/target/debug/foo
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x7a44
(gdb)
I also tried setting the breakpoint using b src/main.rs:2 as well as running just gdb instead of the Rust wrapper rust-gdb both of which resulted in the same outcome. Am I doing this properly?
System Information
/home/a/tmp/foo(HEAD)
09/19/2021 09:07:48.200 AM> uname -a
Linux a 5.13.15_1 #1 SMP Fri Sep 10 16:52:33 UTC 2021 x86_64 GNU/Linux
/home/a/tmp/foo(HEAD)
09/19/2021 09:07:51.291 AM> rustc --version
rustc 1.55.0 (c8dfcfe04 2021-09-06)
/home/a/tmp/foo(HEAD)
09/19/2021 09:07:53.955 AM> gdb --version
GNU gdb (GDB) 10.2
Copyright (C) 2021 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.
I managed to get it working by uninstalling the installed gdb (which was obtained from the Nixpkgs repository) and replacing it with gdb from the Void Linux musl repository. I suspect the gdb from Nixpkgs was built with glibc and is incompatible with the compiled Rust program which was compiled to use musl instead. Usually, the Bedrock Linux userspace that I use allows me to use programs built with different C libraries together, but in this case I guess I needed GDB to be using the same C library as the thing it's trying to debug.
How to install gdb on OSX 10.9?
I try to use macports:
port install gdb
Password:
...
---> Updating database of binaries: 100.0%
---> Scanning binaries for linking errors: 100.0%
---> No broken files found.
But I don't have gdb executable:
$ which gdb
$
I found out that macports gdb on mac is called ggdb. So I make a link:
sudo ln -s /opt/local/bin/ggdb /opt/local/bin/gdb
$ gdb --args ./prog -time
GNU gdb (GDB) 7.6
Copyright (C) 2013 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-apple-darwin13.0.0".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /prog...done.
(gdb) r
Starting program: /prog -time
Unable to find Mach task port for process-id 65740: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
(gdb)
So how to install gdb correctly on OSX 10.9?
P.S. Related questions, which doesn't help:
How to get a "codesigned" gdb on OSX?
"please check gdb is codesigned - see taskgated(8)" - How to get gdb installed with homebrew code signed?
I made it this way (described here):
sudo nano /System/Library/LaunchDaemons/com.apple.taskgated.plist
change option string from -s to -sp at line 22, col 27.
reboot the computer.
Use gdb
I am attempting to use GDB to debug a Stellaris LM3S8962 Evaluation board using OpenOCD and the GNU ARM toolchain (installed with MacPorts), whenever I set the remote target in GDB it always returns "Malfomred response to offset query, qOffsets". Any ideas on what could be going wrong? Is there anything that I am missing?
[bcochran#narada arm]$ arm-none-eabi-gdb
GNU gdb (GDB) 7.3
Copyright (C) 2011 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 "--host=x86_64-apple-darwin10.7.0 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) set remotebaud 115200
(gdb) set debug remote 1
(gdb) file ~/dev/eclipse_workspace/hello_world_arm/bin/main.axf
Reading symbols from /Users/bcochran/dev/eclipse_workspace/hello_world_arm/bin/main.axf...(no debugging symbols found)...done.
(gdb) target remote localhost:4444
Remote debugging using localhost:4444
Sending packet: $qSupported:qRelocInsn+#9a...putpkt: Junk: {{}~Open On
Nak
Sending packet: $qSupported:qRelocInsn+#9a...putpkt: Junk: Chip Debugger
>
Ack
Packet received: qSupported:qRelocInsn+
Packet qSupported (supported-packets) is supported
...
Packet qAttached (query-attached) is supported
Sending packet: $qOffsets#4b...Ack
Packet received: qOffsets
Malformed response to offset query, qOffsets
Here is the openocd output... as soon as the malformed response comes across openocd drops the telnet connection...
[bcochran#narada bin]$ openocd -f ../openocd/luminary.cfg -f ../openocd/stellaris.cfg
Open On-Chip Debugger 0.6.0-dev-00014-g827057f (2011-08-09-22:02)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
500 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lm3s.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : lm3s.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 4444
Error: error during read: Connection reset by peer
Info : dropped 'telnet' connection
Here are the version outputs of my arm-none-eabi-* toolchain...
[bcochran#narada tcl]$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/arm-none-eabi/4.6.1/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-4.6.1/configure --prefix=/opt/local --target=arm-none-eabi --enable-languages=c,objc,c++,obj-c++ --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/arm-none-eabi-gcc --with-system-zlib --disable-nls --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking --enable-multilib --with-newlib --enable-interwork
Thread model: single
gcc version 4.6.1 (GCC)
[bcochran#narada tcl]$ arm-none-eabi-gdb -v
GNU gdb (GDB) 7.3
Copyright (C) 2011 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 "--host=x86_64-apple-darwin10.7.0 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
I am able to compile using the toolchain, and flash the resultant .bin file using OpenOCD. I have been unable to find a solution to the "malformed response" issue just by searching the web.
Thanks in advance for any advice or assistance!
UPDATES
Thanks to answers from #turbo-j and #guy-sirton, I was able to progress a bit further... The most helpful thus far was that I was indeed using the wrong port (4444 instead of 3333) but now I am getting the following whether I add -c "init" -c "halt" -c "reset halt" to my openocd command string or not:
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
Remote 'g' packet reply is too long: 0080004000000000040000220f0000002833405451332abc009600a4d2b86092c0c118c03040d6f0284dbb93204b40c2000000000c010020ffffffff550400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000001
(this is right after the qOffsets req/resp, which now passes)
On the OpenOCD side:
Info : accepting 'gdb' connection from 3333
Warn : acknowledgment received, but no packet pending
Info : dropped 'gdb' connection
With sometimes a undefined debug reason 6 - target needs reset on the OpenOCD console...not sure what is going on now but it seems closer to functioning
UPDATES 2
It seems if I do not load the file 'main.axf' or 'main.o' I do not run into the Remote 'g' packet reply is too long but I get no symbols... I've noticed other websites deal primarily with the .elf extension. What is the difference? I'm using the "Hello World" example from StellarisWare which it generates main.axf, main.bin (flash writes and runs fine), main.d, main.o from the make command. Something odd about my Makefile?
Here is a patch like what #athquad mentioned. See his answer for more information. Thanks to him for efficiently pointing me at the right spot, and great shame indeed for offering a patch without providing it. :-P
http://pastebin.com/rdFF2eZd
Patch was made against openocd commit 631b80fd0835055bb385314f569f589b99d7441d
To use: (./configure options depend on jtag hardware)
git clone git://git.code.sf.net/p/openocd/code openocd
cd openocd
patch -p1 < /path/to/patch/file
./bootstrap
./configure --enable-maintainer-mode --enable-ft2232_libftdi
nice make && sudo make install
You used the wrong port. Use target remote localhost 3333 for the GDB-to-OpenOCD connection. The port 4444 is intended for human interaction via a terminal and can be used in addition to a GDB connection.
If you don't want to compile OpenOCD, as tacos' & atquad's answer, you can use an older release of the GNU ARM tool chain (7.2.5 is fine for example).
(0.4.0 and 0.5.0 windows precompiled are both giving this problem).
I have just encountered the same "'g' packet reply is too long" bug and traced it to its cause.
It seems that for a very long time GNU ARM tools have used an ARM model with 9 obsolete floating point registers. OpenOCD is wise to this and in response to GDB's register request supplies dummy values. However, recent eabi toolchains including GDB have come up to date and so your GDB no longer expects these registers - hence the message.
In the OpenOCD source I have patched armv7m_get_gdb_reg_list() in armv7m.c to make this work, but my patch isn't smart enough to know which GDB version is being used - it simply uses an #ifdef switch - so it would need a bit more work to integrate with the OpenOCD source code.
A patch could be available to anyone who wants.
I do a lot of remote debugging on ARM but with a different processor, OS, and toolchain :-) Nevertheless, here are some thoughts.
This suggestion:
openocd -f openocd.cfg -c "init" -c "halt" -c "reset halt"
Comes from here:
http://michaldemin.wordpress.com/2010/02/22/part-2-debugging-with-gdb-and-openocd/
Otherwise:
A mismatch in the remote gdb protocol between the remote and your gdb. You can try going to a different version of the toolchain. Google and find what works for others.
A communication issue. Try lower baud rate? Make sure the serial port parameters are sound.
From this link: http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
-dH Produce a core dump whenever an error occurs.
So, I compiled a program with a syntax error and the core file was generated. How can that core file be used now? GDB can't be invoked since any executable has not been generated, yet.
[11:11:12 Wed Apr 27]
~/junk1 $ls
core hell.c
[11:11:15 Wed Apr 27]
~/junk1 $gcc -g hell.c -dH
hell.c: In function ‘main’:
hell.c:4: error: expected ‘;’ before ‘}’ token
gcc: Internal error: Aborted (program cc1)
Please submit a full bug report.
See <http://bugs.opensuse.org/> for instructions.
[11:11:36 Wed Apr 27]
~/junk1 $ls
core hell.c
[11:12:09 Wed Apr 27]
~/junk1 $gdb cc1 core
GNU gdb (GDB) SUSE (6.8.91.20090930-2.4)
Copyright (C) 2009 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-suse-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
***cc1: No such file or directory.***
Missing separate debuginfo for the main executable file
Try: zypper install -C "debuginfo(build-id)=41f1efcceccfa5fa0b3476021c731c489547f86e"
Core was generated by `/usr/lib64/gcc/x86_64-suse-linux/4.4/cc1 -quiet hell.c -quiet -dumpbase hell.c'.
Program terminated with signal 6, Aborted.
#0 0x00007fb1b01654e5 in ?? ()
(gdb)
The GDB says: cc1: No such file or directory, in the above output.
How I am supposed to use that core file?
I think that switch is to help debug gcc, not your program. The page you link to starts like this:
3.9 Options for Debugging Your Program or GCC
GCC has various special options that are used for debugging either your program or GCC:
Emphasis mine.
The cc1 program is an internal part of GCC, it is probably somewhere under /usr/lib/ or /usr/libexec/.
gdb -c corefile should work. I haven't had to use the -dH option, so not sure how useful it is in helping with debugging.
I have the following versions of Cygwin, yasm, gcc, and gdb:
CYGWIN_NT-5.1 Thorondor 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
yasm 1.1.0.2352
gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
I've compiled vp8 using the following commands:
$ ./configure --enable-debug
$ make
However when I try to debug using GDB, I get the following error:
$ gdb simple_decoder.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 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 "i686-pc-cygwin"...
Dwarf Error: bad offset (0x4c4000) in compilation unit header (offset
0x0 + 6) [in module /cygdrive/
c/work/vp8/csim/build/simple_decoder.exe]
(gdb) q
Can someone help me out with this?
Thanks,
Arjun
Your compiler and binutils are too old. This was solved circa 2000, the fault comes from the linker (see http://gcc.gnu.org/ml/gcc-bugs/2000-06/msg00768.html)