Is there a way to trace down who sends the sigusr1?
It is for mex file created for Ubuntu, which hangs for certain condition. So I did:
1, mex -g *.c (create .mex file)
2 matlab -Dgdb
3 handle SIGUSR1 stop print
4 run -nojvm (run matlab without gui)
5 dbmex on
6 run my executable
then it prints out:
MEX FILE: /home/X/Desktop/Test/test.mexa 64 entry point located at address 0xd11ea144
Add breakpoints at the debugger prompt and issue a "continue" to resume execution of MATLAB
If I do "continue", my executable runs, then it hangs there again(I think the same as before).
I tried "bt" and "where", but still no clue where I get the SIGUSR1 and why it hangs.
For "where", I get:
#0 0x00007ffff5962ca4 in pthread_cond_wait##GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007ffff69d7015 in mcr_run_main(boost::function0<int> const&, bool, bool)() from /usr/local/MATLAB/R2013b/bin/glnxa64/libmwmcr.so
#2 0x0000000000405291 in ?? ()
#3 0x00007ffff55b0ea5 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
#4 0x0000000000405489 in ?? ()
#5 0x00007fffffffded8 in ?? ()
#6 0x000000000000001c in ?? ()
#7 0x0000000000000002 in ?? ()
#8 0x00007fffffffe208 in ?? ()
#9 0x00007fffffffe234 in ?? ()
#10 0x000000000000000 in ?? ()
Can anyone help here point out the correct way to trace down the signal SIGUSR1 (which I think cause my exe to hang)? Thanks a lot!!
Updates:
set break points as suggested in the source files before and around suspicious code. then continue to track down bugs.
LJ
When stopped at a signal, you can print $_siginfo, and then examine the fields of this object to find the PID of the process that sent the signal.
Related
I'm following the swift getting started documentation and I've installed Swift along with its dependencies in Visual studio:
I added Python (v3.9) to the path (although the guide does use 3.7, I'm not sure whether it would make a difference):
path %ProgramFiles(x86)%\Microsoft Visual Studio\Shared\Python39_64;%PATH%
I also entered this line which supposedly adds a few extra parameters which must be passed to the REPL (not entirely sure what exactly it does):
set SWIFTFLAGS=-sdk %SDKROOT% -I %SDKROOT%/usr/lib/swift -L %SDKROOT%/usr/lib/swift/windows
swift repl -target x86_64-unknown-windows-msvc %SWIFTFLAGS%
This starts the REPL and I'm presented with the following:
Welcome to compnerd.org Swift version 5.6.2 (swift-5.6.2-RELEASE).
Type :help for assistance.
1>
I try to enter 1 + 2 as a test to make sure everything is working properly but I am met with an error instead:
Assertion failed: false && "called into swift language runtime stub", file D:\a\1\s\llvm-project\lldb\source\Plugins\LanguageRuntime\Swift\SwiftLanguageRuntime.cpp, line 369
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
#0 0x00007ff739ced645 (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\lldb.exe+0x1d645)
#1 0x00007ffc6eeb1881 (C:\WINDOWS\System32\ucrtbase.dll+0x71881)
#2 0x00007ffc6eeb2851 (C:\WINDOWS\System32\ucrtbase.dll+0x72851)
#3 0x00007ffc6eeb426e (C:\WINDOWS\System32\ucrtbase.dll+0x7426e)
#4 0x00007ffc6eeb4165 (C:\WINDOWS\System32\ucrtbase.dll+0x74165)
#5 0x00007ffc6eeb44f1 (C:\WINDOWS\System32\ucrtbase.dll+0x744f1)
#6 0x00007ffbf02aa1d5 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x83a1d5)
#7 0x00007ffbf525f724 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x57ef724)
#8 0x00007ffbf5265031 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x57f5031)
#9 0x00007ffbf52628a2 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x57f28a2)
#10 0x00007ffbf525cbcb PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x57ecbcb)
#11 0x00007ffbeffd7d2b PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x567d2b)
#12 0x00007ffbeffe6c52 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x576c52)
#13 0x00007ffbeffb4806 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x544806)
#14 0x00007ffbeff6265a PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4f265a)
#15 0x00007ffbeff6106e PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4f106e)
#16 0x00007ffc6ee61bb2 (C:\WINDOWS\System32\ucrtbase.dll+0x21bb2)
#17 0x00007ffc70947034 (C:\WINDOWS\System32\KERNEL32.DLL+0x17034)
#18 0x00007ffc713a2651 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x52651)
I've tried uninstalling and reinstalling components and playing with the parameters, but to no avail.
Any help would be greatly appreciated.
This is not a true solution, but a workaround that is working on my Windows PC. Assuming Swift is installed on its default location, you need to
set SDKROOT environment variable to C:\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk
(just once in your Windows system environment variables)
instead of running swift repl, you run
lldb "--repl=-sdk %SDKROOT% -target x86_64-unknown-windows-msvc"
(you can make this as a swiftrepl.cmd file and put it into a folder on your path)
as first command you enter
:expr (void*)LoadLibraryA("C:/Program Files/swift/runtime-development/usr/bin/swiftCore.dll")
I know it is ugly, but it works.
lldb "--repl=-sdk %SDKROOT% -target x86_64-unknown-windows-msvc"
Welcome to compnerd.org Swift version 5.7 (swift-5.7-RELEASE).
Type :help for assistance.
1> :expr (void*)LoadLibraryA("C:/Program Files/swift/runtime-development/usr/bin/swiftCore.dll")
(void *) $0 = 0x00007ffa2a090000
1> 1+2
$R0: Int = 3
2> let str="test"
str: String = "test"
I've been able to use flutter to create apps on my mac using my "work user account".
I now want to be able to login as myself and create apps so I've created a new user. I've made the workaccount path to flutter rw for "staff" and using my personalaccount I can access all the files. ls -l confirms I have rw access to the lockfile. I tried deleting the lockfile but that didn't help.
I've updated $PATH and my workaccount flutter is there when I echo.
I've tried killall -9 dart on my workaccount .
When I run flutter doctor -v I still get this:
Flutter failed to open a file at "/Users/workaccount/Development/flutter/bin/cache/lockfile". > The flutter tool cannot access the file or directory.
Please ensure that the SDK and/or project is installed in a location that has read/write permissions for the current user.
#0 throwToolExit (package:flutter_tools/src/base/common.dart:10:3)
#1 _throwFileSystemException (package:flutter_tools/src/base/error_handling_io.dart:778:3)
#2 _handlePosixException (package:flutter_tools/src/base/error_handling_io.dart:726:3)
#3 _runSync (package:flutter_tools/src/base/error_handling_io.dart:583:7)
#4 ErrorHandlingFile.openSync (package:flutter_tools/src/base/error_handling_io.dart:291:12)
#5 Cache.lock (package:flutter_tools/src/cache.dart:304:24)
#6 FlutterCommandRunner.runCommand. (package:flutter_tools/src/runner/flutter_command_runner.dart:240:31)
#7 FlutterCommandRunner.runCommand. (package:flutter_tools/src/runner/flutter_command_runner.dart:236:13)
#8 AppContext.run. (package:flutter_tools/src/base/context.dart:150:29)
#9 AppContext.run. (package:flutter_tools/src/base/context.dart:150:7)
#10 _rootRun (dart:async/zone.dart:1354:13)
#11 _CustomZone.run (dart:async/zone.dart:1258:19)
#12 _runZoned (dart:async/zone.dart:1789:10)
#13 runZoned (dart:async/zone.dart:1711:10)
#14 AppContext.run (package:flutter_tools/src/base/context.dart:149:12)
#15 FlutterCommandRunner.runCommand (package:flutter_tools/src/runner/flutter_command_runner.dart:232:19)
#16 run.. (package:flutter_tools/runner.dart:62:9)
#17 AppContext.run. (package:flutter_tools/src/base/context.dart:150:19)
#18 main (package:flutter_tools/executable.dart:91:3)
My mac skills aren't great, can anyone suggest something that might work?
you may run this command :
$ sudo chown -R <username> /Users/workaccount/Development/flutter/bin/cache/lockfile
more info :
Check permission for the mentioned directory via:
ls -l /home/raphael/flutter/
the flutter subfolder in there should have the same user id (or the group) as your current user, with whom you are trying to create the project.
If not, while being in the folder mentioned above, try to change permission on the folder via:
chown -R YOUR_USERNAME flutter
Run the first command again to verify that the apropriate user is now shown on the folder. Then try to create the project again.
Update
If you want to have permission on each account you can do it:
sudo chmod 777 /Users/workaccount/Development/flutter/bin/cache/lockfile
you go to documents and command+up+. and you can see .bashrc, you must add your path (export PATH="$PATH:/Users/ecemE/flutter/bin"
my path) after terminal off and open again, write flutter doctor and fix this problem :D
I build (brewed) my own perl, then the mod_perl module, and then installed all required perl libraries.
The mod_perl environment works fine. One-liners with Math::PARI also work, for example:
perl -MMath::Pari -e "use Math::Pari ':float', 'type_name'; warn type_name 22222222222222222222222;"
t_INT at -e line 1.
However, when I start apache2/mod_perl and try to load Math::PARI I get the following crash:
root#paris:/usr/apps/test/config# gdb -q /usr/sbin/apache2
Reading symbols from /usr/sbin/apache2...(no debugging symbols found)...done.
(gdb) set args -f /usr/apps/test/config/httpd.conf -k start
(gdb) run
Starting program: /usr/sbin/apache2 -f /usr/apps/test/config/httpd.conf -k start
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff367bea7 in moveoffstack_newer_than () from /opt/perl5/perlbrew/perls/perl-5.14.2/lib/site_perl/5.14.2/x86_64-linux-thread-multi/auto/Math/Pari/Pari.so
(gdb) bt
#0 0x00007ffff367bea7 in moveoffstack_newer_than () from /opt/perl5/perlbrew/perls/perl-5.14.2/lib/site_perl/5.14.2/x86_64-linux-thread-multi/auto/Math/Pari/Pari.so
#1 0x00007ffff367c008 in XS_Math__Pari_DESTROY () from /opt/perl5/perlbrew/perls/perl-5.14.2/lib/site_perl/5.14.2/x86_64-linux-thread-multi/auto/Math/Pari/Pari.so
#2 0x00007ffff5bca17c in Perl_pp_entersub () from /opt/perl5/perlbrew/perls/perl-5.14.2/lib/5.14.2/x86_64-linux-thread-multi/CORE/libperl.so
#3 0x00007ffff5b5c771 in Perl_call_sv () from /opt/perl5/perlbrew/perls/perl-5.14.2/lib/5.14.2/x86_64-linux-thread-multi/CORE/libperl.so
#4 0x00007ffff5bd0629 in Perl_sv_clear () from /opt/perl5/perlbrew/perls/perl-5.14.2/lib/5.14.2/x86_64-linux-thread-multi/CORE/libperl.so
#5 0x00007ffff5bd0ce2 in Perl_sv_free2 () from /opt/perl5/perlbrew/perls/perl-5.14.2/lib/5.14.2/x86_64-linux-thread-multi/CORE/libperl.so
#6 0x00007ffff5bcb647 in S_visit () from /opt/perl5/perlbrew/perls/perl-5.14.2/lib/5.14.2/x86_64-linux-thread-multi/CORE/libperl.so
#7 0x00007ffff5bd1456 in Perl_sv_clean_objs () from /opt/perl5/perlbrew/perls/perl-5.14.2/lib/5.14.2/x86_64-linux-thread-multi/CORE/libperl.so
#8 0x00007ffff5b5e4a7 in perl_destruct () from /opt/perl5/perlbrew/perls/perl-5.14.2/lib/5.14.2/x86_64-linux-thread-multi/CORE/libperl.so
#9 0x00007ffff7f8d477 in modperl_perl_destruct () from /opt/perl5/perlbrew/perls/perl-5.14.2/usr/lib/apache2/modules/mod_perl.so
#10 0x00007ffff7f7d81e in modperl_interp_destroy () from /opt/perl5/perlbrew/perls/perl-5.14.2/usr/lib/apache2/modules/mod_perl.so
#11 0x00007ffff7f7e3c5 in modperl_tipool_destroy () from /opt/perl5/perlbrew/perls/perl-5.14.2/usr/lib/apache2/modules/mod_perl.so
#12 0x00007ffff7f7d882 in modperl_interp_pool_destroy () from /opt/perl5/perlbrew/perls/perl-5.14.2/usr/lib/apache2/modules/mod_perl.so
#13 0x00007ffff776499e in apr_pool_destroy () from /usr/lib/libapr-1.so.0
#14 0x00007ffff7764b95 in apr_pool_clear () from /usr/lib/libapr-1.so.0
#15 0x0000555555585e67 in main ()
More info about the environment:
Debian 7.11
perl-5.14.2 (same as system perl but built with perlbrew)
mod_perl2 (built manually)
How can I get to the root cause of this?
Math::Pari is not thread safe, so probably you are running under threaded MPM, try installing prefork model for Apache2. If you're on Debian/Ubuntu try this:
sudo apt-get install apache2-mpm-prefork
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
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.