I am trying to debug my swift program using lldb in terminal. I have compiled my code with the command
swiftc hello.swift
then I ran lldb using
lldb hello
in the lldb program I tried to set a break point using
(lldb) breakpoint set --file hello.swift --line 10
but I got the error
Breakpoint 2: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
here is the code for hello.swift:
func answer()-> Int{
var value = 12
value = value + 9
return 4 * value
}
let arr = [0, 1, 2, 3, 4]
for _ in arr{
print(answer())
}
what am I doing wrong?
You should set the -g option when compiling the program. From swiftc --help:
-g Emit debug info. This is the preferred setting for debugging with LLDB.
Example session:
% swiftc -g hello.swift
% lldb hello
(lldb) target create "hello"
Current executable set to '/tmp/x/hello' (x86_64).
(lldb) breakpoint set --file hello.swift --line 10
Breakpoint 1: where = hello`main + 256 at hello.swift:10:11, address = 0x0000000100003bf0
(lldb) run
Process 15967 launched: '/tmp/x/hello' (x86_64)
Process 15967 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x0000000100003bf0 hello`main at hello.swift:10:11
7 let arr = [0, 1, 2, 3, 4]
8
9 for _ in arr{
-> 10 print(answer())
11 }
Target 0: (hello) stopped.
Related
I am using below command to start the training of deepspeech model
%cd /content/DeepSpeech
!python3 DeepSpeech.py \
--drop_source_layers 2 --scorer /content/DeepSpeech/data/lm/kenlm-nigerian.scorer\
--train_cudnn True --early_stop True --es_epochs 6 --n_hidden 2048 --epochs 5 \
--export_dir /content/models/ --checkpoint_dir /content/model_checkpoints/ \
--train_files /content/train.csv --dev_files /content/dev.csv --test_files /content/test.csv \
--learning_rate 0.0001 --train_batch_size 64 --test_batch_size 32 --dev_batch_size 32 --export_file_name 'he_model_5' \
--max_to_keep 3
I keep getting following error again and again.
(0) Invalid argument: Not enough time for target transition sequence (required: 28, available: 24)0You can turn this error into a warning by using the flag ignore_longer_outputs_than_inputs
(1) Invalid argument: Not enough time for target transition sequence (required: 28, available: 24)0You can turn this error into a warning by using the flag ignore_longer_outputs_than_inputs
Following worked for me
Go to
DeepSpeech/training/deepspeech_training/train.py
Now look for following particular line (Normally in 240-250)
total_loss = tfv1.nn.ctc_loss(labels=batch_y, inputs=logits, sequence_length=batch_seq_len)
Change it to as following
total_loss = tfv1.nn.ctc_loss(labels=batch_y, inputs=logits, sequence_length=batch_seq_len, )
-bash-3.2$ uname -a
SunOS b2s-sol10spr-1 5.10 Generic_147147-26 sun4v sparc sun4v
-bash-3.2$ dbx -V
Sun DBX Debugger 8.0 SunOS_sparc 2014/10/21
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 8.0' in your .dbxrc
(dbx)
I'm getting a weird issue where the debugger is just showing completely wrong values for function parameters & local/member variables.
Here's a sample backtrace
=>[1] SQLGetDiagRecW(HandleType = -28417, Handle = 0x480000000101dfc1, RecNumber = -12288, Sqlstate = (nil), NativeError = 0xffffffff7fffdf, MessageText = 0x9100000001002bbd, BufferLength = -9583, TextLength = 0x380000000101da91), line 3154 in "CInterface.cpp"
[2] extract_diag_error_w(htype = 3, handle = 0x3, connection = 0x1014d32c0, head = 0x101e5a5e0, return_code = -1, save_to_diag = 0), line 4447 in "__info.c"
[3] function_return_ex(level = 3, handle = 0x101e5a1a0, ret_code = -1, save_to_diag = 0), line 4863 in "__info.c"
[4] SQLExecDirectW(statement_handle = 0x101e5a1a0, statement_text = 0x101dacde0, text_length = -3), line 442 in "SQLExecDirectW.c"
<truncated>
Frame 1 is in the problematic shared library, while the other frames are in the unixODBC libodbc.so
If we look at the code for extract_diag_error_w (you can get the code from http://www.unixodbc.org/unixODBC-2.3.1.tar.gz, the following snippet is from DriverManager/__info.c )
ret = SQLGETDIAGRECW( connection,
head -> handle_type,
handle,
rec_number,
sqlstate,
&native,
msg1,
sizeof( msg1 ),
&len );
Note that we have, elsewhere
#define SQLGETDIAGRECW(con,typ,han,rn,st,nat,msg,bl,tlp)\
(con->functions[77].funcW)\
(typ,han,rn,st,nat,msg,bl,tlp)
in dbx, if I go to frame 2 and print head -> handle_type, I get 3, but if I go to frame 1 and print HandleType, I get -28417.
I'd expect dbx, if it can't find the value (due to optimization or w/e, even though this was a debug build), to tell me so (<value optimized out> or somesuch). Also, every value I look at seems to be wrong (I've confirmed that the debugger is lying to me via control flow, there's code like if (x < 0) throw ...; where dbx claims it's some negative number, but the exception doesn't get thrown.
The problematic shared libary was built on another machine (while unixODBC was built locally), so maybe that's involved? It was also built w/ gcc, where I used the default compiler when building unixODBC (though I think it's also w/ gcc, since they both have a dependency on libgcc_s.so.1)
Any suggestions? (I'd guess updating dbx might work, but it would be difficult in this environment).
edit: Here's an example w/ local variables
(dbx) next
t#1 (l#1) stopped in Simba::Support::ODBCStringConverter::ConvertWStringToSQLWCHARString at line 64 in file "ODBCStringConverter.cpp"
64 simba_int32 length = in_length;
(dbx) next
t#1 (l#1) stopped in Simba::Support::ODBCStringConverter::ConvertWStringToSQLWCHARString at line 66 in file "ODBCStringConverter.cpp"
66 if (0 == in_length)
(dbx) print length
length = 11
(dbx) print in_length
in_length = 419430399
(dbx) next
t#1 (l#1) stopped in Simba::Support::ODBCStringConverter::ConvertWStringToSQLWCHARString at line 73 in file "ODBCStringConverter.cpp"
73 else if (SIMBA_NTS == in_length)
(dbx) next
t#1 (l#1) stopped in Simba::Support::ODBCStringConverter::ConvertWStringToSQLWCHARString at line 79 in file "ODBCStringConverter.cpp"
79 simba_int32 bufferBytes = length;
(dbx) next
t#1 (l#1) stopped in Simba::Support::ODBCStringConverter::ConvertWStringToSQLWCHARString at line 80 in file "ODBCStringConverter.cpp"
80 if (!in_isLengthInBytes)
(dbx) print bufferBytes
bufferBytes = 1744830464
(dbx)
edit 2: Here's how the troublesome library was built (need to rebuild unixODBC, will do that later).
Example command for compiling one of the .cpp files (I removed a bunch of include directories)
/opt/csw/gcc4/bin/g++ -DSIZEOF_LONG_INT=8 -DSQL_WCHART_CONVERT -DHAVE_MEMMOVE -m64 -fPIC -pthread -Wall -Wno-unknown-pragmas -DSIMBA -D_REENTRANT -DCLUNIX -DNDEBUG -D_POSIX_PTHREAD_SEMANTICS -O0 -g -D_DEBUG -c Common/QSTableMetadataFile.cpp -o Common/QSTableMetadataFile_solaris10sparc_gcc4_9_debug64.cpp.o
Command used to link (removed a bunch of .o files)
/opt/csw/gcc4/bin/g++ -DSIMBA -D_REENTRANT -m64 -fPIC -pthread -Wall -Wno-unknown-pragmas -lrt -O0 -g -shared -L/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/icu/53.1.x/solaris10sparc/gcc4_9/release64/lib -lstdc++ -licudata_sb64 -licui18n_sb64 -licuuc_sb64 -lpthread -lm -lsocket -lnsl -Wl,-M,exports_SunOS.map -Wl,-zallextract,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libSimbaDSI.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libSimbaSupport.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libAEProcessor.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libCore.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libDSIExt.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libExecutor.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libParser.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libSimbaODBC.a -Wl,-zweakextract -o ../Bin/solaris10sparc/gcc4_9/debug64/libQuickstart64.so
I am currently trying to learn swift and while I was coding some dummy stuff, I noticed the xcode is skipping some lines and sometimes stops on weird lines . my env: macos sierra,xcode Version 8.2.1 (8C1002)
since xcode is skipping some lines , I thought the problem is from code optimisation , then I switched to terminal to debug, below is the input&output
I compiled using
swiftc -g -Onone *.swift
then
load it with lldb
lldb main
set breakpoint on lint 18 as shown below and process run with "r"
17 do {
-> 18 try StaticM.teststatic2()
19 print (1)
20 }catch {
21
(lldb) thread step-in
Process 963 stopped
* thread #1: tid = 0x86e1, 0x0000000100001f6a main`static StaticM.teststatic2(self=main.StaticM, $error=Error # 0x00007fff5fbffac0) throws -> () + 26 at staticExt.swift:13, queue = 'com.apple.main-thread', stop reason = step in
frame #0: 0x0000000100001f6a main`static StaticM.teststatic2(self=main.StaticM, $error=Error # 0x00007fff5fbffac0) throws -> () + 26 at staticExt.swift:13
10 public extension StaticM {
11 #discardableResult
12 public static func teststatic2() throws {
-> 13 var asdf=2;
14 let sdfgsdfg=2;
15 print(sdfgsdfg);
16 print (asdf);
(lldb) n
Process 963 stopped
* thread #1: tid = 0x86e1, 0x0000000100001f72 main`static StaticM.teststatic2(self=main.StaticM, $error=Error # 0x00007fff5fbffac0) throws -> () + 34 at staticExt.swift:15, queue = 'com.apple.main-thread', stop reason = step over
frame #0: 0x0000000100001f72 main`static StaticM.teststatic2(self=main.StaticM, $error=Error # 0x00007fff5fbffac0) throws -> () + 34 at staticExt.swift:15
12 public static func teststatic2() throws {
13 var asdf=2;
14 let sdfgsdfg=2;
-> 15 print(sdfgsdfg);
16 print (asdf);
17 asdf += 1;
18 }
(lldb) process continue
Process 963 resuming
2
2
1
Process 963 exited with status = 0 (0x00000000)
(lldb)
question is , after I go to next line using "n" in lldb, why lldb skips line 14 of staticExt.swift and jumps straight to line 15 ?
also , sometimes when trying to debug some other program, I click on "step-in" in xcode, it stops on the declaration line of the func instead of first line in the code block, I clicked stepover , it goes back to the caller func line instead of executing the first line of that func.
in all,programe works , but why lldb jumps even with -Onone and -g ?
could you please let me where can I find more info ?
thank you very much.
Swift's basic types (Int's, Strings, etc.) are formally somewhat heavy-weight - for instance in your example:
(lldb) expr --raw -- asdf
(Swift.Int) $R0 = {
_value = 3
}
To make performance acceptable even though this is true, the swift compiler "unboxes" these types in common operations and applies other "optimization-like" tricks to make all this go faster. Since this is such a pervasive feature of swift, it does so even at -Onone, to make performance of unoptimized code acceptable. And once the optimizer starts getting involved, it sometimes can't help itself and will do more work than maybe it should at -Onone.
In this case, because the first variable is a "let" of an Int, swiftc knows it can just directly insert the value into the arguments when it goes to call print, so it doesn't need to make up a variable. If you change the let to a var then code will actually be generated for that line, and the line will get its own line table entry.
If you know how to read assembly code, you can look at the mixed disassembly to see this in action.
In lldb:
(lldb) dis -m -f
will give you mixed disassembly of the current frame.
I am trying to use mtimesx library on matlab 2016a, win 10 64bit, I compile this library and the following code runs in command window:
>> a=rand(2,4,2);
>> b=rand(4,5,2);
>> d=mtimesx(a,b)
d(:,:,1) =
0.5234 0.7756 0.6265 0.7531 0.6579
0.6256 0.3926 0.3557 0.7522 0.4804
d(:,:,2) =
0.6398 0.8713 0.8695 0.3040 0.6066
1.2157 1.0177 1.2590 0.5510 1.1960
but when I'm trying to run it as a script following error occurs:
Undefined function or variable 'mtimesx'.
Error in Untitled2 (line 25)
d=mtimesx(a,b);
and after that this function don't work in command window until I compile it again.
Thank you
the problem solved by making following changes in mtimesx_build.m:
1.changing mexopts = [prefdir '\mexopts.bat']; to ----> mexopts =[prefdir'\mex_C++_win64.xml'];
changing x = findstr(tline,'COMPILER=cl'); to ---> x = findstr(tline,'COMPILER="cl"');
I'm using GNU octave 3.6.4. According to the changelog (v 3.2):
Moving up and down the call stack with
dbup and dbdown now works.
However, when I'm in debug mode and excecute dbup followed by dbnext, the next line in the lower frame will be executed. Why is this so and how can it be avoided?
octave -q
octave:1> myfunc_base(2,3)
stopped in /home/seb/octave/myfunc.m at line 5
5: keyboard
debug> dbstack
stopped in:
--> myfunc at line 5 [/home/seb/octave/myfunc.m]
myfunc_base at line 4 [/home/seb/octave/myfunc_base.m]
debug> dbup
stopped in myfunc_base at line 4 % <-- looks good!
debug> dbnext
stopped in /home/seb/octave/myfunc.m at line 6 % <-- damn this is the old frame!
6: sp = a + temp;
debug>
The two test functions:
myfunc.m
function sp = myfunc (a, b, c)
temp = b+c;
keyboard
sp = a + temp;
end
myfunc_base.m
function sp = myfunc_base (aa, bb)
temp = myfunc(aa, aa, bb);
sp = aa + temp;
end
To step out you have to use dbstep out. This matches the behaviour of matlab and everything else would be very stange. You can not step to the next line on any level of the stack if an exception occurs.