I have a core generated. /var/log/messages displays this line:
Jan 29 07:50:40 NetAcc-02 kernel: LR.exe[15326]: segfault at 51473861 ip 081e2dba sp 00240030 error 4 in LR.exe[8048000+34c000]
Jan 29 07:50:52 NetAcc-02 abrt[20696]: saved core dump of pid 15252 (/home/netacc/active/LR.exe) to /var/spool/abrt/ccpp-2015-01-29-07:50:40-15252.new/coredump (1642938368 bytes)
Jan 29 07:50:52 NetAcc-02 abrtd: Directory 'ccpp-2015-01-29-07:50:40-15252' creation detected
Jan 29 07:50:54 NetAcc-02 abrtd: Executable '/home/netacc/active/LR.exe' doesn't belong to any package
Jan 29 07:50:54 NetAcc-02 abrtd: Corrupted or bad dump /var/spool/abrt/ccpp-2015-01-29-07:50:40-15252 (res:2), deleting
Does the last line mean that the core is corrupted? Because a bt of my corefile seems to be corrupted:
#0 0x081e2dba in CfaPepDecision (pBuf=0xa0d6735, pIp=0x5147384d, u2DirectFlag=1, ppepserver=0x67684e6f, paccl=0x45517377, pPepMode=0x6a31396c "") at /home/TAN/release/rel/idu-sw/pep/pep/src/pepcfa.c:498
#1 0x52367331 in ?? ()
#2 0x0a0d6735 in gProfileVsatTable ()
#3 0x5147384d in ?? ()
#4 0x75417875 in ?? ()
#5 0x38000200 in ?? ()
Strangely the gProfileVsatTable is a global array!
The address pIp = 0x5147384d is out of bounds in gdb.
Any inputs are helpful.
Because a bt of my corefile seems to be corrupted:
This is usually the result of analyzing the wrong binary. Invoke GDB like this:
gdb /home/netacc/active/LR.exe \
/var/spool/abrt/ccpp-2015-01-29-07:50:40-15252.new/coredump
Make sure that you have not updated the binary since Jan 29 07:50:52. In particular, make sure you did not rebuild the binary with different options after the crash.
Related
I am debugging an application crash using the net-snmp library. The backtrace is as follows:
#0 0x001a1c7e in _snmp_parse (sessp=0x0, session=<value optimized out>, pdu=0xb6183858, data=0xa3401248 "\301", length=12097984) at snmp_api.c:4408
#1 0x001a20bb in snmp_resend_request (slp=0x0, rp=0xb6184818, incr_retries=1) at snmp_api.c:6383
#2 0x00b89944 in send_trap_to_sess (sess=0xb6122848, template_pdu=0xa3401440) at agent_trap.c:945
#3 0x00b8ab46 in netsnmp_send_traps (trap=-1, specific=-1, enterprise=0xbbd080, enterprise_length=10, vars=0xa5400468, context=0x0, flags=0)
at agent_trap.c:839
#4 0x00b8b0fa in send_enterprise_trap_vars (trap=-1, specific=-1, enterprise=0xbbd080, enterprise_length=10, vars=0xa5400468) at agent_trap.c:863
#5 0x00b8b153 in send_trap_vars (trap=-1, specific=-1, vars=0xa5400468) at agent_trap.c:975
#6 0x00b8b1fe in send_v2trap (vars=0xa5400468) at agent_trap.c:1049
#7 0x00288382 in applicationBaseClass::sendTraps (temp=0x161d3018) at appBaseClass.cpp:750
#8 0x00288311 in applicationBaseClass::sendTrapsByTimer (temp=0x161d3018) at appBaseClass.cpp:736
#9 0x00ac05f3 in check_timers () at exec_timer.c:383
I installed the net-snmp-debuginfo to get the source files. The details:
net-snmp-libs-5.5-57.el6_8.1.i686
net-snmp-utils-5.5-57.el6_8.1.i686
net-snmp-debuginfo-5.5-57.el6_8.1.i686
net-snmp-5.5-57.el6_8.1.i686
We can see that the source files correspond to the net-snmp version installed - 5.5-57
Now my application is linking to net-snmp :
[root#stg blr]# lsof -p 4043 | grep snmp
serv_trans 4043 root mem REG 8,2 1760620 4031 /usr/lib/libnetsnmpmibs.so.20.0.0
serv_trans 4043 root mem REG 8,2 701880 4978 /usr/lib/libnetsnmp.so.20.0.0
serv_trans 4043 root mem REG 8,2 313568 3982 /usr/lib/libnetsnmpagent.so.20.0.0
serv_trans 4043 root mem REG 8,2 157008 4017 /usr/lib/libnetsnmphelpers.so.20.0.0
So the application is rightly linking with the net-snmp libraries of version 5.5-57
Now, to the backtrace. The stack seems to be incorrect. It is not showing the exact call sequence. For example, in the frame 2, the line number that gdb shows- 6383 -is actually a declaration statement.
#1 0x001a20bb in snmp_resend_request (slp=0x0, rp=0xb6184818, incr_retries=1) at snmp_api.c:6383
6383 u_char *pktbuf = NULL, *packet = NULL;
What could be I missing? I seem to be having the right source files for gdb. Why isn't the stack trace from gdb not pointing to the exact sequence of events?
I'd like to print the output of a program in php in "real time" (buffers are not important). The process takes a long time and having the (partial) data earlier would be very helpful.
Usually I'd use plain passthru() but this is done in CakePHP and it doesn't output anything until I do this:
$this->response->file($file, array('download' => true));
return $this->response;
If I just remove these lines and swap the exec() with a passthru() I get a MissingViewException
Error: [MissingViewException] View file "Songs/download.ctp" is missing.
And If I do this
$this->response=$out; #$out being the output of exec()
return $this->response;
I get this
2015-08-10 01:18:06 Error: Fatal Error (1): Call to a member function body() on string in [/storage/www/sonerezh/lib/Cake/Controller/Controller.php, line 960]
2015-08-10 01:18:06 Error: [InternalErrorException] Internal Server Error
Request URL: /songs/download/2307
Stack Trace:
#0 /storage/www/sonerezh/lib/Cake/Error/ErrorHandler.php(213): ErrorHandler::handleFatalError(1, 'Call to a membe...', '/storage/www/so...', 960)
#1 [internal function]: ErrorHandler::handleError(1, 'Call to a membe...', '/storage/www/so...', 960, Array)
#2 /storage/www/sonerezh/lib/Cake/Core/App.php(931): call_user_func('ErrorHandler::h...', 1, 'Call to a membe...', '/storage/www/so...', 960, Array)
#3 /storage/www/sonerezh/lib/Cake/Core/App.php(904): App::_checkFatalError()
#4 [internal function]: App::shutdown()
#5 {main}
What can I do?
You could try this (not tested):
$this->response->body(function () {
passthru ('./program') ;
}) ;
return $this->response ;
More information here.
Note: I assumed your were using CakePHP 3 since CakeResponse::file does not exist in CakePHP 2.
I have a lot of warning when trying to run Selenium2 tests through codeception. The tests work though.
These are the warning if someone can lead me on the right way to correct :
C:\Users\Bebop\Documents\Site Internet\Sites\prestashop1.5.6\modules\paypal>php
codecept.phar run Selenium
Codeception PHP Testing Framework v1.7.0.2
Powered by PHPUnit 3.7.27 by Sebastian Bergmann.
PHP Warning: array_merge(): Argument #2 is not an array in phar://C:/Users/Bebo
p/Documents/Site Internet/Sites/prestashop1.5.6/modules/paypal/codecept.phar/src
/Codeception/Module/Selenium2.php on line 70
PHP Stack trace:
PHP 1. {main}() C:\Users\Bebop\Documents\Site Internet\Sites\prestashop1.5.6\m
odules\paypal\codecept.phar:0
PHP 2. require_once() C:\Users\Bebop\Documents\Site Internet\Sites\prestashop1
.5.6\modules\paypal\codecept.phar:7
PHP 3. Symfony\Component\Console\Application->run() phar://C:/Users/Bebop/Docu
ments/Site Internet/Sites/prestashop1.5.6/modules/paypal/codecept.phar/codecept:
29
PHP 4. Symfony\Component\Console\Application->doRun() phar://C:/Users/Bebop/Do
cuments/Site Internet/Sites/prestashop1.5.6/modules/paypal/codecept.phar/vendor/
symfony/console/Symfony/Component/Console/Application.php:121
PHP 5. Symfony\Component\Console\Application->doRunCommand() phar://C:/Users/B
ebop/Documents/Site Internet/Sites/prestashop1.5.6/modules/paypal/codecept.phar/
vendor/symfony/console/Symfony/Component/Console/Application.php:191
PHP 6. Symfony\Component\Console\Command\Command->run() phar://C:/Users/Bebop/
Documents/Site Internet/Sites/prestashop1.5.6/modules/paypal/codecept.phar/vendo
r/symfony/console/Symfony/Component/Console/Application.php:897
PHP 7. Codeception\Command\Run->execute() phar://C:/Users/Bebop/Documents/Site
Internet/Sites/prestashop1.5.6/modules/paypal/codecept.phar/vendor/symfony/cons
ole/Symfony/Component/Console/Command/Command.php:244
PHP 8. Codeception\Command\Run->runSuites() phar://C:/Users/Bebop/Documents/Si
te Internet/Sites/prestashop1.5.6/modules/paypal/codecept.phar/src/Codeception/C
ommand/Run.php:83
PHP 9. Codeception\Codecept->runSuite() phar://C:/Users/Bebop/Documents/Site I
nternet/Sites/prestashop1.5.6/modules/paypal/codecept.phar/src/Codeception/Comma
nd/Run.php:115
PHP 10. Codeception\SuiteManager->__construct() phar://C:/Users/Bebop/Documents
/Site Internet/Sites/prestashop1.5.6/modules/paypal/codecept.phar/src/Codeceptio
n/Codecept.php:124
PHP 11. Codeception\SuiteManager->initializeModules() phar://C:/Users/Bebop/Doc
uments/Site Internet/Sites/prestashop1.5.6/modules/paypal/codecept.phar/src/Code
ception/SuiteManager.php:48
PHP 12. Codeception\Module\Selenium2->_initialize() phar://C:/Users/Bebop/Docum
ents/Site Internet/Sites/prestashop1.5.6/modules/paypal/codecept.phar/src/Codece
ption/SuiteManager.php:62
PHP 13. array_merge() phar://C:/Users/Bebop/Documents/Site Internet/Sites/prest
ashop1.5.6/modules/paypal/codecept.phar/src/Codeception/Module/Selenium2.php:70
Warning: array_merge(): Argument #2 is not an array in phar://C:/Users/Bebop/Doc
uments/Site Internet/Sites/prestashop1.5.6/modules/paypal/codecept.phar/src/Code
ception/Module/Selenium2.php on line 70
Call Stack:
0.0117 1074720 1. {main}() C:\Users\Bebop\Documents\Site Internet\Sites
\prestashop1.5.6\modules\paypal\codecept.phar:0
0.0208 1373568 2. require_once('phar://C:/Users/Bebop/Documents/Site In
ternet/Sites/prestashop1.5.6/modules/paypal/codecept.phar/codecept') C:\Users\Be
bop\Documents\Site Internet\Sites\prestashop1.5.6\modules\paypal\codecept.phar:7
0.0667 4331624 3. Symfony\Component\Console\Application->run() phar://C
:/Users/Bebop/Documents/Site Internet/Sites/prestashop1.5.6/modules/paypal/codec
ept.phar/codecept:29
0.0785 4941624 4. Symfony\Component\Console\Application->doRun() phar:/
/C:/Users/Bebop/Documents/Site Internet/Sites/prestashop1.5.6/modules/paypal/cod
ecept.phar/vendor/symfony/console/Symfony/Component/Console/Application.php:121
0.0791 4941624 5. Symfony\Component\Console\Application->doRunCommand()
phar://C:/Users/Bebop/Documents/Site Internet/Sites/prestashop1.5.6/modules/pay
pal/codecept.phar/vendor/symfony/console/Symfony/Component/Console/Application.p
hp:191
0.0792 4941624 6. Symfony\Component\Console\Command\Command->run() phar
://C:/Users/Bebop/Documents/Site Internet/Sites/prestashop1.5.6/modules/paypal/c
odecept.phar/vendor/symfony/console/Symfony/Component/Console/Application.php:89
7
0.0802 4941992 7. Codeception\Command\Run->execute() phar://C:/Users/Be
bop/Documents/Site Internet/Sites/prestashop1.5.6/modules/paypal/codecept.phar/v
endor/symfony/console/Symfony/Component/Console/Command/Command.php:244
0.1596 9010384 8. Codeception\Command\Run->runSuites() phar://C:/Users/
Bebop/Documents/Site Internet/Sites/prestashop1.5.6/modules/paypal/codecept.phar
/src/Codeception/Command/Run.php:83
0.1597 9010720 9. Codeception\Codecept->runSuite() phar://C:/Users/Bebo
p/Documents/Site Internet/Sites/prestashop1.5.6/modules/paypal/codecept.phar/src
/Codeception/Command/Run.php:115
0.1675 9175200 10. Codeception\SuiteManager->__construct() phar://C:/Use
rs/Bebop/Documents/Site Internet/Sites/prestashop1.5.6/modules/paypal/codecept.p
har/src/Codeception/Codecept.php:124
0.1756 10263064 11. Codeception\SuiteManager->initializeModules() phar://
C:/Users/Bebop/Documents/Site Internet/Sites/prestashop1.5.6/modules/paypal/code
cept.phar/src/Codeception/SuiteManager.php:48
0.1867 11096264 12. Codeception\Module\Selenium2->_initialize() phar://C:
/Users/Bebop/Documents/Site Internet/Sites/prestashop1.5.6/modules/paypal/codece
pt.phar/src/Codeception/SuiteManager.php:62
0.1914 11529024 13. array_merge() phar://C:/Users/Bebop/Documents/Site In
ternet/Sites/prestashop1.5.6/modules/paypal/codecept.phar/src/Codeception/Module
/Selenium2.php:70
============= At this time the tests begins
←[1mSelenium Tests (1) ←[0m-----------------------------------------------------
--------------
Trying to ←[35;1mlogin in backoffice←[0m (PrestaShopModuleListCest.install_the_m
odule) Ok
--------------------------------------------------------------------------------
-------
Time: 27.79 seconds, Memory: 16.25Mb
←[30;42m←[2KOK (1 test, 0 assertions)
←[0m←[2K
Ok, Found out what was wrong :
I had a missing space in my Selenium.suite.yml which did not convert my capabilities in an array :
capabilities:
unexpectedAlertBehaviour: 'accept'
This was the good thing to do
I am working on a perl script that has multiple database calls and I continuously get the following error:
DB-Library error:
Attempt to initiate a new SQL Server operation with results pending.
In my code I have the following:
The first call to the database performs a number of insert statements built from a hash:
while (my ($key, $value) = each(%holidays)) {
system("log4k", "DEBUG", "$0", "Staging holiday info data for: $cal_name: $key");
$sql = "INSERT INTO stg_holiday_data (hol_mnemonic, hol_date, hol_comment, dml_type) VALUES (\"$cal_name\", $key, \"$value\", \"N\")";
system("log4k", "TRACE", "$0", "SQL being executed: $sql");
if ($test == 0) {
$dbh->dbcmd($sql);
($dbh->dbsqlexec() && $dbh->dbresults)
or &fatalError("Database error in $sql", "DB_ERROR");
while($dbh->dbresults != NO_MORE_RESULTS) {
while(my #dat = $dbh->dbnextrow){}
}
}
}
immediately after that finishes I close off the connection, and cancel it to make sure that there are no results left to be processed by issuing:
$dbh->dbcancel();
$dbh->dbclose();
From there I call a separate subroutine to execute a stored procedure which will produce three lines of output signifying row numbers:
subroutine call
&run_sproc() if ($test == 0);
subroutine:
sub run_sproc() {
system("log4k", "DEBUG", "$0", "Loading staged holiday data");
my $sql1 = "upd_holiday_data";
system("log4k", "TRACE", "$0", "SQL being executed: $sql1");
my($dbh2) = new Sybase::DBlib $ENV{DATABASE_USER}, $ENV{DATABASE_PASSWORD}, $ENV{DATABASE_SERVER}, "GME_calendar_sync";
&fatalError("Failed to login imagine database", "DB_LOGIN_ERROR") unless ($dbh2);
$dbh2->dbcmd($sql1);
($dbh2->dbsqlexec() && $dbh2->dbresults )
or &fatalError ("Database error in $sql", "DB_ERROR");
while ($dbh2->dbresults != NO_MORE_RESULTS) {
while (my #d = $dbh2->dbnextrow) {
system("log4k", "TRACE", "$0", "Next row being inserted #d");
}
}
$dbh2->dbclose();
}
I do have a third SQL block that comes after the stored procedure that works fine with or without this subroutine.
What is happening is I am receiving the error mentioned above right before the results from the stored procedure print. I have tried everything I can imagine to make sure that all the results are being processed. A sample of the log output is below:
[Tuesday, 23 October 2012 13:30:02 BST] [DEBUG] gme_process_calendars.pl: Staging holiday info data for: CA: 20251226
[Tuesday, 23 October 2012 13:30:03 BST] [TRACE] gme_process_calendars.pl: SQL being executed: INSERT INTO stg_holiday_data (hol_mnemonic, hol_date, hol_comment, dml_type) VALUES ("CA", 20251226, "upload", "N")
[Tuesday, 23 October 2012 13:30:03 BST] [DEBUG] gme_process_calendars.pl: Staging holiday info data for: CA: 20220103
[Tuesday, 23 October 2012 13:30:03 BST] [TRACE] gme_process_calendars.pl: SQL being executed: INSERT INTO stg_holiday_data (hol_mnemonic, hol_date, hol_comment, dml_type) VALUES ("CA", 20220103, "upload", "N")
[Tuesday, 23 October 2012 13:30:03 BST] [DEBUG] gme_process_calendars.pl: Loading staged holiday data
[Tuesday, 23 October 2012 13:30:03 BST] [TRACE] gme_process_calendars.pl: SQL being executed: upd_holiday_data
DB-Library error:
Attempt to initiate a new SQL Server operation with results pending.
[Tuesday, 23 October 2012 13:30:03 BST] [TRACE] gme_process_calendars.pl: Next row being inserted 310107230
Any help with this would be greatly appreciated as I have already tried everything I can find doing an internet search and reading the documentation.
Thanks
I think your problem is that your run_proc method tries to execute this SQL:
my $sql1 = "upd_holiday_data";
which I doubt is a valid SQL command
Solution Found:
In the run_sproc sub routine, the check:
($dbh2->dbsqlexec() && $dbh2->dbresults )
or &fatalError ("Database error in $sql", "DB_ERROR");
the second condition $dbh2->dbresults is what is causing this error condition, once this was removed the error did not come up anymore.
My program is statically compiled with dietlibc. It is compiled on ubuntu x64 (compiled for x86 using the -m32 flag) and is run on a centos x86.
The compiled size is only about 100KB. I compile it with -ggdb3 and no optimization flags.
My program uses signal.h to handle a SIGSEGV signal and then calls abort().
The program runs without problems for days but sometimes segfaults. This is when I get weird backtraces that I do not understand:
username#ubuntu:~/Desktop$ gdb -c core.28569 program-name
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
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-linux-gnu --target=i386-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from program-name...done.
[New Thread 28569]
Core was generated by `program-name'.
Program terminated with signal 6, Aborted.
#0 0x00914410 in __kernel_vsyscall ()
Setting up the environment for debugging gdb.
Function "internal_error" not defined.
Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
Function "info_command" not defined.
Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
.gdbinit:8: Error in sourced command file:
Argument required (one or more breakpoint numbers).
(gdb) bt
#0 0x00914410 in __kernel_vsyscall ()
During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0x914411.
#1 0x0804d7f4 in __unified_syscall ()
#2 0xbf8966c0 in ?? ()
#3
#4 0x2054454e in ?? ()
#5 0x20524c43 in ?? ()
#6 0x2e352e33 in ?? ()
#7 0x32373033 in ?? ()
#8 0x2e203b39 in ?? ()
#9 0x2054454e in ?? ()
#10 0x20524c43 in ?? ()
#11 0x2e302e33 in ?? ()
#12 0x32373033 in ?? ()
#13 0x4d203b39 in ?? ()
#14 0x61696465 in ?? ()
#15 0x6e654320 in ?? ()
#16 0x20726574 in ?? ()
#17 0x36204350 in ?? ()
#18 0x203b302e in ?? ()
#19 0x54454e2e in ?? ()
#20 0x43302e34 in ?? ()
#21 0x00000029 in ?? ()
#22 0xbf8989a8 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) bt full
#0 0x00914410 in __kernel_vsyscall ()
No symbol table info available.
#1 0x0804d7f4 in __unified_syscall ()
No symbol table info available.
#2 0xbf8966c0 in ?? ()
No symbol table info available.
#3
No symbol table info available.
#4 0x2054454e in ?? ()
No symbol table info available.
#5 0x20524c43 in ?? ()
No symbol table info available.
#6 0x2e352e33 in ?? ()
No symbol table info available.
#7 0x32373033 in ?? ()
No symbol table info available.
#8 0x2e203b39 in ?? ()
No symbol table info available.
#9 0x2054454e in ?? ()
No symbol table info available.
#10 0x20524c43 in ?? ()
No symbol table info available.
#11 0x2e302e33 in ?? ()
No symbol table info available.
#12 0x32373033 in ?? ()
No symbol table info available.
#13 0x4d203b39 in ?? ()
No symbol table info available.
#14 0x61696465 in ?? ()
No symbol table info available.
#15 0x6e654320 in ?? ()
No symbol table info available.
#16 0x20726574 in ?? ()
No symbol table info available.
#17 0x36204350 in ?? ()
No symbol table info available.
#18 0x203b302e in ?? ()
No symbol table info available.
#19 0x54454e2e in ?? ()
No symbol table info available.
#20 0x43302e34 in ?? ()
No symbol table info available.
#21 0x00000029 in ?? ()
No symbol table info available.
#22 0xbf8989a8 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) quit
It's a stack overrun.
#4 0x2054454e in ?? ()
That looks like text, " TEN" or "NET "
#5 0x20524c43 in ?? ()
" RLC" or "CLR "
And so on.
Treat the addresses as if they were text - see if you can identify where this text overwrites your stack.
Your stack trace is actually very easy to understand:
You got SIGSEGV somewhere,
Your signal handler did whatever it does, then called abort()
Which issued raise(2) system call, by calling __unified_syscall()
The reason you get no stack trace in GDB is that
__unified_syscall is implemented in assembly, and
does not use frame pointer, and
does not have proper cfi directives to describe how to unwind from it.
I would consider this a bug in dietlibc, quite easy to fix, actually. See if this (untested) patch fixes it for you:
--- dietlibc-0.31/i386/unified.S.orig 2011-03-13 10:16:23.000000000 -0700
+++ dietlibc-0.31/i386/unified.S 2011-03-13 10:21:32.000000000 -0700
## -31,8 +31,14 ## __unified_syscall:
movzbl %al, %eax
.L1:
push %edi
+ cfi_adjust_cfa_offset (4)
+ cfi_rel_offset (edi, 0)
push %esi
+ cfi_adjust_cfa_offset (4)
+ cfi_rel_offset (esi, 0)
push %ebx
+ cfi_adjust_cfa_offset (4)
+ cfi_rel_offset (ebx, 0)
movl %esp,%edi
/* we use movl instead of pop because otherwise a signal would
destroy the stack frame and crash the program, although it
## -61,8 +67,11 ## __unified_syscall:
#endif
.Lnoerror:
pop %ebx
+ cfi_adjust_cfa_offset (-4)
pop %esi
+ cfi_adjust_cfa_offset (-4)
pop %edi
+ cfi_adjust_cfa_offset (-4)
/* here we go and "reuse" the return for weak-void functions */
#include "dietuglyweaks.h"
If you can't rebuild dietlibc, or if the patch is incorrect, you may still be able to analyze the stack trace better. As far as I can tell, __unified_syscall does not touch %ebp. So you might be able to get a reasonable stack trace by doing this:
define xbt
set $xbp = (void **)$arg0
while 1
x/2a $xbp
set $xbp = (void **)$xbp[0]
end
end
xbt $ebp
Note: if the xbt works, it is likely to go into the weeds around the SIGSEGV signal frame (that frame does not use frame pointer either). This may result in complete garbage, or in a skipped frame or two (which would be exactly the frames where SIGSEGV happened).
So you really are much better off getting proper unwind descriptors into dietlibc.