I want to realize transaction Match .can I use chronicle in it ? and How to use it ?
thanks. I am writing log with it.but some error happend like :
Problematic frame:
J 927 C2 net.openhft.chronicle.wire.BinaryWire.copyOne(Lnet/openhft/chronicle/wire/WireOut;)V (751 bytes) # 0x000000011291e0d4 [0x000000011291ce20+0x12b4]
Register to memory mapping:
RAX=0x0000000797b8ba58 is an oop
[C
- klass: {type array char}
- length: 76
RBX=0x0000000000c00000 is an unknown value
RCX=0x0000000000000007 is an unknown value
RDX=0x0000000797b8ba40 is an oop
java.lang.StringBuilder
- klass: 'java/lang/StringBuilder'
RSP=0x000070000752b3a0 is pointing into the stack for thread: 0x00007f9cc7806800
RBP=0x00000000f2f7174b is an unknown value
RSI=0x0000000000c00055 is an unknown value
RDI=0x0000000000000004 is an unknown value
R8 =0x0000000797b75cf8 is an oop
net.openhft.chronicle.bytes.MappedBytes
- klass: 'net/openhft/chronicle/bytes/MappedBytes'
R9 =0x0000000000000006 is an unknown value
R10=0x00000001123cffff is an unknown value
R11=0x00000000f2f71748 is an unknown value
R12=0x0000000000000000 is an unknown value
R13=0x00000001123cffff is an unknown value
R14=0x00000000f2f71637 is an unknown value
R15=0x00007f9cc7806800 is a thread.
it is information in hs_err_pid73671.log .is there some bug with my code?
Related
I have a virtual address (instruction pointer) of the function, obtained from backtrace call. I need to figure out the debug information about it.
For example, I need the information about attach_backtraces function.
nm -a Backtrace.so | grep attach_backtraces
000000000002cdfe t _ZN2xsL17attach_backtracesENS_3RefE
The offset 0x2cdfe can be determined by substracting from PC (IP) the .so loaded address. And it matches the output from nm.
The following infrormation I get from readelf -w Backtrace.so
<3><3a14f>: Abbrev Number: 0
<2><3a150>: Abbrev Number: 161 (DW_TAG_subprogram)
<3a152> DW_AT_name : (indirect string, offset: 0x21bf5): attach_backtraces
<3a156> DW_AT_decl_file : 22
<3a157> DW_AT_decl_line : 201
<3a158> DW_AT_decl_column : 13
<3a159> DW_AT_declaration : 1
<3a159> DW_AT_sibling : <0x3a163>
<3><3a15d>: Abbrev Number: 1 (DW_TAG_formal_parameter)
<3a15e> DW_AT_type : <0x36aac>
<3><3a162>: Abbrev Number: 0
Why it's offset is 0x21bf5 and not the expected 0x2cdfe? What a piece do I miss? My next step would be query DWARF-info for the function at the offset 0x2cdfe to get debug info.
PS. I'm gathering full backtrace, where symbol name, file and line should be presented. What C/C++ library are better to use to parse/get information from DWARF ?
Addon:
No, there are no other attach_backtraces in the readelf -w output. I have found that
DW_AT_sibling : <0x3a163>
and it's definition:
No, there are no other attach_backtraces in the readelf -w output. I have found that
DW_AT_sibling : <0x3a163>
and it's definition:
<1><3f9f5>: Abbrev Number: 27 (DW_TAG_subprogram)
<3f9f6> DW_AT_specification: <0x3a163>
<3f9fa> DW_AT_low_pc : 0x2c59e
<3fa02> DW_AT_high_pc : 0x860
<3fa0a> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<3fa0c> DW_AT_GNU_all_tail_call_sites: 1
<3fa0c> DW_AT_sibling : <0x3fb21>
0x2c59e (DW_AT_low_pc) - 0x860 (DW_AT_high_pc) = 0x2cdfe (the target function address).
Is this calculation correct?
Why it's offset is 0x21bf5 and not the expected 0x2cdfe?
The offset 0x21bf5 is the offset of the name of the symbol ("attach_backtraces" here) in the .debug_str section (where the names off all types, parameters, variables and functions are collected).
That offset has absolutely no relation to the value of the symbol being represented (0x2cdfe here). These offsets just happened to be close to each other to confuse you.
What a piece do I miss?
Normally, a function should have DW_AT_low_pc attribute which represents its starting address (and the value of that attribute for attach_backtraces routine described by your output would be 0x2cdfe).
I am not sure why you are missing low_pc and high_pc here.
One possibility is that there are actually many instances of xs::attach_backtraces(xs::Ref) routine (if it's declared as inline in a header file), and the instance that you are looking at in readelf -w output was discarded by the linker (the function will appear in all object files which #included that header, but the linker will only keep a single instance of the function). If this is the case, look for another attach_backtraces in readelf -w output, with low_pc and high_pc present.
In first block of DWARF dump <3a150> (where we can see offset to function name, 0x21bf5) we also see DW_AT_declaration flag which indicates that declaration of a function was not completed in this DIE (see section 2.13 of DWARF 5 documentation).
To find the completion of declaration you should find DIE with DW_AT_specification attribute, which value is a reference to DIE which it completes (as in your 2nd block, <3f9f5>) and should have in your case value <3a150>.
Taking care on mentioned above I suppose that your 2nd block is not what you want to find since it references to another DIE <0x3a163>.
When you'll find right block, then you should use DW_AT_low_pc as a parameter you need (offset to 'attach_backtraces' from process base address).
Hope this helps.
Also, from my point of view dwarfdump tool shows a better output than readelf.
I am trying to put together and example of coding inline assembly code in a 'C' program. I have not had any success. I am using GCC 4.9.0. As near as I can tell my syntax is correct. However the build blows up with the following errors:
/tmp/ccqC2wtq.s:48: Error: syntax error; found `(', expected `,'
Makefile:51: recipe for target 'all' failed
/tmp/ccqC2wtq.s:48: Error: junk at end of line: `(31)'
/tmp/ccqC2wtq.s:49: Error: syntax error; found `(', expected `,'
/tmp/ccqC2wtq.s:49: Error: junk at end of line: `(9)'
These are related to the input/output/clobbers lines in the code. Anyone have an idea where I went wrong?
asm volatile("li 7, %0\n" // load destination address
"li 8, %1\n" // load source address
"li 9, 100\n" // load count
// save source address for return
"mr 3,7\n"
// prepare for loop
"subi 8,8,1\n"
"subi 9,9,1\n"
// perform copy
"1:\n"
"lbzu 10,2(8)\n"
"stbu 10,2(7)\n"
"subi 9,9,1\n" // Decrement the count
"bne 1b\n" // If zero, we've finished
"blr\n"
: // no outputs
: "m" (array), "m" (stringArray)
: "r7", "r8"
);
It's not clear what you are trying to do with the initial instructions:
li 7, %0
li 8, %1
Do you want to load the address of the variables into those registers? In general, this is not possible because the address is not representable in an immediate operand. The easiest way out is to avoid using r7 and r8, and instead use %0 and %1 directly as the register names. It seems that you want to use these registers as base addresses, so you should use the b constraint:
: "b" (array), "b" (stringArray)
Then GCC will take care of the details of materializing the address in a suitable fashion.
You cannot return using blr from inline assembler because it's not possible to tear down the stack frame GCC created. You also need to double-check the clobbers and make sure that you list all the things you clobber (including condition codes, memory, and overwritten input operands).
I was able to get this working by declaring a pair of pointers and initializing them with the addresses of the arrays. I didn't realize that the addresses wouldn't be available directly. I've used inline assembly very sparsely in the past, usually just
to raise or lower interrupt masks, not to do anything that references variables. I just
had some folks who wanted an example. And the "blr" was leftover when I copied a
snipet of a pure assembly routine to use as a starting point. Thanks for the responses.
The final code piece looks like this:
int main()
{
char * stringArrayPtr;
unsigned char * myArrayPtr;
unsigned char myArray[100];
stringArrayPtr = (char *)&stringArray;
myArrayPtr = myArray;
asm volatile(
"lwz 7,%[myArrayPtr]\n" // load destination address
"lwz 8, %[stringArrayPtr]\n" // load source address
"li 9, 100\n" // load count
"mr 3,7\n" // save source address for return
"subi 8,8,1\n" // prepare for loop
"subi 9,9,1\n"
"1:\n" // perform copy
"lbzu 10,1(8)\n"
"stbu 10,1(7)\n"
"subic. 9,9,1\n" // Decrement the count
"bne 1b\n" // If zero, we've finished
// The outputs / inputs / clobbered list
// No output variables are specified here
// See GCC documentation on extended assembly for details.
:
: [stringArrayPtr] "m" (stringArrayPtr), [myArrayPtr]"m"(myArrayPtr)
: "7","8","9","10"
);
}
I'm trying to understand the following symbol dump from the LLDB shell
(lldb) target create --no-dependents '9.0/Symbols/Library/Application Support/WatchKit/WK'
Current executable set to '9.0/Symbols/Library/Application Support/WatchKit/WK' (armv7k).
(lldb) image list
[ 0] 675ED1EB-BAA0-3453-B7B1-3E69310F40FD 0x00004000 9.0/Symbols/Library/Application Support/WatchKit/WK
(lldb) image dump symtab
Dumping symbol table for 1 modules.
Symtab, file = 9.0/Symbols/Library/Application Support/WatchKit/WK, num_symbols = 6:
Debug symbol
|Synthetic symbol
||Externally Visible
|||
Index UserID DSX Type File Address/Value Load Address Size Flags Name
------- ------ --- --------------- ------------------ ------------------ ------------------ ---------- ----------------------------------
[ 0] 0 Code 0x0000000000007fcc 0x0000000000000030 0x001e0000 stub helpers
[ 1] 1 X Data 0x0000000000004000 0x0000000000003fcc 0x000f0010 _mh_execute_header
[ 2] 2 X ReExported 0x000b0000 main -> /System/Library/PrivateFrameworks/SockPuppetGizmo.framework/SockPuppetGizmo`_SPApplicationMain
[ 3] 3 X Undefined 0x0000000000000000 0x0000000000000000 0x00010100 _SPApplicationMain
[ 4] 4 X Undefined 0x0000000000000000 0x0000000000000000 0x00010500 dyld_stub_binder
[ 5] 5 S Trampoline 0x0000000000007ffc 0x0000000000000004 0x00000000 main
Most of it I can kinda understand because there are addresses and sizes associated with the symbol but some of them I don't understand. In this case there are 2 "undefined" symbols with 0x00 for the address and 0x00 for the size. My question is what do those symbols mean? Does that mean they are resolved at runtime and I really shouldn't be concerned about them when trying to make sense of things in crash logs?
Your guess is correct, Undefined symbols are symbols that one binary wants to use from some other binary. They will get fixed up by the loader when your program runs.
So for instance, if you write the standard "hello world" program, the main binary will have an Undefined symbol for "printf". BTW, these are the same as the symbols of type U that you see in the output of nm.
I need to get the average age in each gender group...
Here is my data set:
01::F::21::0001
02::M::31::21345
03::F::22::33323
04::F::18::123
05::M::31::14567
Basically this is
userid::gender::age::occupationid
Since there is multiple delimiter, i read somewhere here in stackoverflow to load it first via TextLoader()
loadUsers = LOAD '/user/cloudera/test/input/users.dat' USING TextLoader() as (line:chararray);
testusers = FOREACH loadusers GENERATE FLATTEN(STRSPLIT(line,'::')) as (user:int, gender:chararray, age:int, occupation:int);
grunt> DESCRIBE testusers;
testusers: {user: int,gender: chararray,age: int,occupation: int}
grouped_testusers = GROUP testusers BY gender;
average_age_of_testusers = FOREACH grouped_testusers GENERATE group, AVG(testusers.age);
after running
dump average_age_of_testusers
this is the error in hdfs
2016-10-31 13:39:22,175 [main] ERROR org.apache.pig.tools.pigstats.SimplePigStats -
ERROR 0: Exception while executing (Name: grouped_testusers: Local Rearrange[tuple]{chararray}(false) - scope-284 Operator Key: scope-284): org.apache.pig.backend.executionengine.ExecException:
ERROR 2106: Error while computing average in Initial 2016-10-31 13:39:22,175 [main]
ERROR org.apache.pig.tools.pigstats.PigStatsUtil - 1 map reduce job(s) failed!
Input(s):
Failed to read data from "/user/cloudera/test/input/users.dat"
Output(s):
Failed to produce result in "hdfs://quickstart.cloudera:8020/tmp/temp-169204712/tmp-1755697117"
This is my first try in programming in pig, so forgive me if the solution is very obvious.
Analyzing it further, it seems it has trouble computing the average, i thought i made a mistake in data type but age is int.
if you can help me, thank you.
I figured out the problem in this one. Please refer to How can correct data types on Apache Pig be enforced? for a better explanation.
But then, just to show what I did... I had to cast my data
FOREACH loadusers GENERATE FLATTEN((tuple(int,chararray,int,int)) STRSPLIT(line,'::')) as (user:int, gender:chararray, age:int, occupation:int);
AVG is failing because loadusers.age is being treated as string instead of int.
I am trying to generate a dynamic assembly using Reflection & Emit in .NET. I am getting an error, "Common Language Runtime detected an invalid program." I created another program which has the functionality I want using hard-coded types. The functionality I am trying to write will ultimately use dynamic types, but I can use ILDasm to see the IL I need to generate. I am comparing the IL I am generating with the IL which the compiler generates. In the .locals init declaration of one method I see there is an extra item in the compiler-generated code,
compiler-generated:
.locals init ([0] class [System.Core]System.Linq.Expressions.ParameterExpression CS$0$0000,
[1] class [System.Core]System.Linq.Expressions.ParameterExpression[] CS$0$0001)
mine:
.locals init (class [System.Core]System.Linq.Expressions.ParameterExpression V_0,
class [System.Core]System.Linq.Expressions.ParameterExpression[] V_1)
I don't understand the significance of the "[0]" and "[1]" in the compiler-generated code. Can anyone tell me what it means?
As a more general question, I can follow most ILDasm output without too much trouble. But every so often I run across a problematic expression. For instance, in this line from ILDasm
callvirt instance class [EntityFramework]System.Data.Entity.ModelConfiguration.EntityTypeConfiguration`1<!!0> [EntityFramework]System.Data.Entity.DbModelBuilder::Entity<class DynamicEdmxTrial.HardFooAsset>()
the "!!0" probably refers to the generic type of the Entity<>, but I don't know for sure, and I wonder if there is a key to ILDasm output that would explain its more obscure output to me.
The specification is freely available here. It takes a little getting used to, but most details are easily found once you figure out the structure.
!! is listed in II.7.1 Types:
Type ::= | Description | Clause
‘!’ Int32 | Generic parameter in a type definition, | §II.9.1
| accessed by index from 0 |
| ‘!!’ Int32 | Generic parameter in a method | §II.9.2
| definition, accessed by index from 0 |
...
In other words, inside a method that C# would call f<T, U>(), !!0 would be T, and !!1 would be U.
However, the [0] is a good question. The spec does not seem to address it. The .locals directive is described in II.15.4.1.3 The .locals directive, which lists the syntax as
MethodBodyItem ::= ...
| .locals [ init ] ‘(’ LocalsSignature ‘)’
LocalsSignature ::= Local [ ‘,’ Local ]*
Local ::= Type [ Id ]
There is nothing that seems to allow [0] there unless it is part of a Type, and Type does not allow anything starting with [ either. My guess is that this is an undocumented peculiarity specific to Microsoft's implementation, intended to help the human reader see that location 0 is local variable CS$0$0000, for when the generated instructions access local variables by index.
Experimenting with ILAsm shows that this is exactly what it means. Taking a simple C# program:
static class Program {
static void Main() {
int i = 0, j = 1;
}
}
and compiling and then disassembling it (csc test.cs && ildasm /text test.exe >test.il) shows:
....
.locals init (int32 V_0,
int32 V_1)
IL_0000: nop
IL_0001: ldc.i4.0
IL_0002: stloc.0
IL_0003: ldc.i4.1
IL_0004: stloc.1
IL_0005: ret
....
Modifying the .locals to
.locals init ([0] int32 V_0, [0] int32 V_1)
gives a useful warning message:
test.il(41) : warning : Local var slot 0 is in use
And indeed, declaring variables of different types, then reordering them using [2], [1], [0], assembling and immediately disassembling the result, shows that the variables got reordered.