Since I installed Delphi XE7 I have this nasty crash as shutdown:
Description:
Stopped working
Problem signature:
Problem Event Name: APPCRASH
Application Name: bds.exe
Application Version: 21.0.17707.5020
Application Timestamp: 545bd62d
Fault Module Name: rtl210.bpl
Fault Module Version: 21.0.17707.5020
Fault Module Timestamp: 545bd940
Exception Code: c0000005
Exception Offset: 00016a9c
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 1033
After I click the 'Close program' I get:
Exception EAccessViolation in module rtl210.bpl at 00016A9C.
Access violation at address 50066A9C in module 'rtl210.bpl'. Read of
address 075F2AF8.
I checked the call stack but it doesn't really makes any sense.
To see the call stack I started Delphi, then in 'Load process' I entered Delphi's path ( "C:\Delphi\XE7\bin\bds.exe" ).
I cannot set the '-p delphi' parameter in 'Parameters' box because when the second Delphi process is started it will complain that it cannot access the license file (which is blocked by the first Delphi process).
Call stack:
:50066a9c rtl210.#System##IntfClear$qqrr44System#%DelphiInterface$17System#IInterface% + 0x10
:08baffdd fmx210.#System#Generics#Collections#%TList__1$56System#%DelphiInterface$29Fmx#Behaviormanager#IListener%%#SetCount$qqri + 0x49
:50061099 rtl210.#System##Halt0$qqrv + 0xb1
:77378bd4 ntdll.wcsncmp + 0x88
:77342710 ; ntdll.dll
:7737cb10 ntdll.LdrUnloadDll + 0x4a
:753b8be4 KERNELBASE.FreeLibrary + 0x82
:2063a191 coreide210.#Exptmain#TExpertLib#$bdtr$qqrv + 0xa9
:5005f10b rtl210.#System#TObject#Free$qqrv + 0xb
:5070ba40 vcl210.#Vcl#Forms#TCustomForm#$bdtr$qqrv + 0x58
:210f57c0 designide210.#Deskform#TDesktopForm#$bdtr$qqrv + 0x40
:761aee1c kernel32.BaseThreadInitThunk + 0x12
:7738399b ntdll.RtlInitializeExceptionChain + 0xef
:7738396e ntdll.RtlInitializeExceptionChain + 0xc2
It says something about FMX but I never do FMX projects (still too unripe to be used). So I disable it.
What could cause the crash?
This is a Delphi bug
SOLUTION: Enable 'FMX Standard Components' package.
Details: I turned out that I had the 'FMX Standard Components' package disabled - Seems logical to disable such a large library since I don't use it.
Well... Delphi don't like that! I enabled the library back and now I have no crash!
I could have delete the question since nobody answered posted any answer but I thought it will be useful to keep it. It documents a very important feature of Delphi: crash when the developer won't use FMX lib :)
Here a snippet of generated .c code from .Lex.
And the Coredump is coming at the very first Iteration
while (1) /* loops until end-of-file is reached */{
yy_cp = yy_c_buf_p;
/* Support of yytext. */
*yy_cp = yy_hold_char; // receiving coredump here
/* yy_bp points to the position in yy_ch_buf of the start of
* the current run.*/
yy_bp = yy_cp;
yy_current_state = yy_start;}
Here you can find code
I have answer of my own question. Here are some explanation of Solution
I have two .Lex (Type1_Lex.l & Type2_Lex.l)and two .Yacc (Type1_Yacc.y & Type2_Yacc.y) code
I am compiling all and relevant .c (Type1_Lex.c, Type2_Lex.c, Type1_Yacc.c & Type2_Yacc.v) and .h files are getting generated
And further compilation of .c with generates Type1_Lex.o, Type2_Lex.o, Type1_Yacc.o Type2_Yacc.o
Further I am putting all these object files in a single .a
The Problems are Here
...
ld: Warning: size of symbol `yy_create_buffer' changed from 318 in libuperbe.a(TYPE1_Lex.o) to 208 in libxxx.a (TYPE2_Lex.o)
ld: Warning: size of symbol `yy_load_buffer_state' changed from 262 in libuperbe.a(TYPE1_Lex.o) to 146 in libxxx.a(TYPE2_Lex.o)
ld: Warning: size of symbol `yy_init_buffer' changed from 278 in libuperbe.a(TYPE1_Lex.o) to 164 in libxxx.a(TYPE2_Lex.o)
Some symbols are same in both generated .c (TYPE1_Lex.c & TYPE2_Lex.c)
When both object file bind in a single .a the similar
(yy_create_buffer,yy_init_buffer,yy_load_buffer_state) symbols got
overridden.
At the runtime when the methods yy_create_buffer(),yy_init_buffer(), yy_load_buffer_state() should be called defined in TYPE2_Lex.c but in actual those methods are called from the file TYPE1_Lex.c and the leads to the memory corruption some how.
For moving ahead I decided to use sed with following patterns :
Sed TYPE2_Lex.c with :
s/yy_create_buffer()/TYPE1_create_buffer/g
s/yy_init_buffer()/TYPE1_init_buffer/g
s/yy_load_buffer_state()/TYPE1_load_buffer_state/g
Sed TYPE2_Lex.c with
s/yy_create_buffer()/TYPE2_create_buffer/g
s/yy_init_buffer()/TYPE2_init_buffer/g
s/yy_load_buffer_state()/TYPE2_load_buffer_state/g
So that the Loader can easily differentiate the symbol. And at the run time confusion between the methods name become null.
After all these Step I am able to move ahead :)
Thanks all for your help :)
In my debugging, I tried to get Delphi to reveal or expose the value of FTestResult (TStrings). The Delphi's debugger shows in "FTestResult ()" in watch window.
private
FTestThread:TTestThread;
FTestState:TState;
FTestResult:TStrings; //represent a list of strings.
........
........
FTestResult.Clear();
FTestResult.Add('EmployeeId=''' + TMainForm(Application.MainForm).UserId.Text + '''');
........
Is this normal if it produces nothing in () after add?
Please advise... Thanks
Is this normal if it produces nothing in () after calling Add?
Yes this is the expected behaviour. Delphi 7 does not have a bespoke debugger visualizer for TStrings. This functionality was added in Delphi 2010. You'll have to find some other way to inspect the contents of this object in Delphi 7.
The () is the output of the standard visualizer for an instance of a class. Inside the parens are the data members, of which TStrings has none.
When I get a crash report, the offending part of my code will sometimes look like this, instead of showing me the actual line number, even though the crash report is symbolicated:
-[ViewController myMethod:] + 47
In order to debug this, I need to know what line of my code this represents so that I can visually inspect it, set a breakpoint, etc.
What is a good way to get the address of a method plus offset, as shown above, using LLDB?
NOTE: this question is NOT a duplicate of how to read a crash report. I know how to read a crash report. I am asking very specifically how to get the corresponding line using LLDB. Nothing in the other answers shows how to do that. They are quite verbose and go into all kinds of things about dealing with crash reports and debugging in general, but don't show what the specific steps on LLDB are. Please do not duplicate this bug.
[note this ONLY works if you save Archives in XCode of all the builds you released]
Information you need to collect first:
APPNAME: the short name of your app as seen in the Archive directory (typically the XCode Target name; you will see it immediately when you look at the Archive directory in Finder below).
CRASHING_FUNCTION_NAME: name of function shown in useless Apple backtrace (in the OP's example, -[ViewController myMethod:])
ARCH: architecture of device that crashed. Most likely the right value is either armv7 or arm64. If you don't know, try both.
Ok here are the steps:
In XCode go to Window...Organizer...Archives
Right-click on the Archive for the release the crashing user has, and choose Show in Finder
open a Terminal shell and cd to that directory shown in Finder
execute the following in the shell:
lldb -arch ARCH Products/Applications/APPNAME.app/APPNAME
inside lldb do the following:
(lldb) add-dsym dSYMs/APPNAME.app.dSYM/Contents/Resources/DWARF/APPNAME
(lldb) disassemble --name CRASHING_FUNCTION_NAME
you now see a rich disassembly with symbols, and lo and behold, each line shows the same decimal offset as the original useless Apple backtrace (in the OPs example, the useless offset was 47), as in:
APPNAME[0xf4a7c] <+47>: ldr r0, [r0, r1]
you might be able to figure out the corresponding source line just from this information, if the disassembly has enough symbols to help you figure out where you are.
if not, there is another great trick. Pass the address of the line that crashed:
(lldb) image lookup -v --address 0xf4a7c
Now lldb shows you a rich collection of information---much richer than what is shown by Apple stack backtraces even when they do contain line numbers, and much richer than lldb source list---about all the source lines that contributed to the assembler instruction at that address. Pay close attention to both the Summary and LineEntry sections. Example:
Address: APPNAME[0x000f4a7c] (APPNAME.__TEXT.__text + 963740)
Summary: APPNAME`myclass::myfunc(bool, bool) + 904 [inlined] std::__1::deque<mystruct, std::__1::allocator<mystruct> >::operator[](unsigned long) + 22 at myfile.cpp:37945
APPNAME`myclass::myfunc(bool, bool) + 882 [inlined] myinlinefunc(int) + 14 at myfile.cpp:65498
APPNAME`myclass::myfunc(bool, bool) + 868 at myfile.cpp:65498
Module: file = "/Users/myuser/mydir/arch/Products/Applications/APPNAME.app/APPNAME", arch = "armv7"
CompileUnit: id = {0x000483a4}, file = "/Users/myuser/mydir/myfile.cpp", language = "objective-c++"
Function: id = {0x0045edde}, name = "myfunc", range = [0x000f46f4-0x000f572a)
FuncType: id = {0x0045edde}, decl = myfile.cpp:65291, compiler_type = "void (_Bool, _Bool)"
Blocks: id = {0x0045edde}, range = [0x000f46f4-0x000f572a)
id = {0x0045f7d8}, ranges = [0x000f4936-0x000f51c0)[0x000f544c-0x000f5566)[0x000f5570-0x000f5698)
id = {0x0046044c}, ranges = [0x000f49c6-0x000f49ce)[0x000f49d6-0x000f49d8)[0x000f4a2e-0x000f4a38)[0x000f4a58-0x000f4a82), name = "myinlinefunc", decl = myfile.cpp:37938, mangled = _Z11myinlinefunci, demangled = myinlinefunc(int)
id = {0x00460460}, ranges = [0x000f4a58-0x000f4a64)[0x000f4a66-0x000f4a82), name = "operator[]", decl = deque:1675, mangled = _ZNSt3__15dequeI12mystructNS_9allocatorIS1_EEEixEm, demangled = std::__1::deque<mystruct, std::__1::allocator<mystruct> >::operator[](unsigned long)
LineEntry: [0x000f4a7c-0x000f4a82): /Applications/Xcode7.3.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/deque:1678:14
Symbol: id = {0x00000805}, range = [0x000f46f4-0x000f572a), name="myclass::myfunc(bool, bool)", mangled="_ZN7myclass7myfuncEbb"
Variable: id = {0x00460459}, name = "myvar1", type = "int", location = , decl = myfile.cpp:37938
Variable: id = {0x0045f7dd}, name = "myvar2", type = "bool", location = , decl = myfile.cpp:65583
Variable: id = {0x0045edf2}, name = "this", type = "myclass *", location = [sp+56], decl =
Variable: id = {0x0045ee01}, name = "myvar3", type = "bool", location = , decl = myfile.cpp:65291
Variable: id = {0x0045ee0e}, name = "myvar4", type = "bool", location = , decl = myfile.cpp:65292
In this example under Summary, we can see that the line that crashed was actually a combination of code from myclass::myfunc(), myinlinefunc() and std::deque::operator[]. This kind of mashing together is very common for optimized code. This is often enough information to find the offending source line of your code. Under LineEntry we see the line number for the most-nested code contributing to that assembler line, which in this case is in the STL std::deque code, but in other cases might be the exact line number you want in your code.
Now the only remaining question is: why on earth doesn't Apple just do this for us in the original backtrace? They clearly have all this information themselves! Why do they make us jump through such hoops? What are they hiding?
Your steps (image lookup + p/x addr + offset) will give you the raw address, as you found. But the original crash report probably included an address before the method + offset --- it is just as easy to slide your binary to the correct address using target modules load. At the end of the crash report there should be a list of the binary images present in the program, including load address and UUID.
But more importantly, while the address is nice what you're really after is the source location. In that case, once you've determined the correct address for the method (or slid it to the matching address via target modules load), you can use source list
(lldb) so l -a `addr + offset`
I'm using the backtick notation here which does an in-line expression evaluation. There's a handy shortcut for most commands that take an address: if you omit spaces, you can write the expression without backticks:
(lldb) so l -a addr+offset
You can also use image lookup with an address. If you have debug information, this will tell you what the current location of variables are at this point. Why is this useful? Because most crash reports include the register context at crash and so any variables that are currently in a register are provided to you (-v is necessary to get all of the register location information).
(lldb) im loo -v -a addr+offset
Finally -- this isn't going to work because you're dealing with an Objective-C method name -- but with a simple C function name you can do the offset arithmetic in-line as long as you cast the function name to a pointer type (it's not legal C to add an offset to a function pointer). e.g.
(lldb) so l -a (char*)main+10
Here is something I found that worked:
First you need to find the address of the method itself.
image lookup -v -F "-[ViewController myMethod:]"
in the result you will see a lot of info, but the range part will give you want you want
... range = [0x000708c0-0x00070c6c) ...
(where 0x000708c0 is address of method)
Now to add the given offset of 47, just use LLDB to do that math for you:
(lldb) p/x 0x000708c0 + 47
(int) $0 = 0x000708ef
and you get your answer, the offending line is on 0x000708ef
Or better yet, based on Jason Molenda's answer, is to just go straight to the code listing, which will show the line number:
(lldb) source list -a `0x000708c0 + 47`
EDIT: improved based on the answer from Jason Molenda
I was trying to get XForms going on my Ubuntu desktop. There does not
appear to be much activity on XForms at the moment and I was trying to
get Backplanejs running. It did not work, and upon examining the javascript
I found it relied Microsoft libraries and activex.
Rather than learn javascript I decided to continue my erlang education and
struggled with xmerl instead. I created a directory for schemas with an
index file. The contents of this directory is:
tony#blessing:~/workspace/myXformProject$ ls schemas
SchemaList.txt XForms-Schema.xsd xhtml-lat1.ent xml-events.xsd
SchemaList.txt~ xhtml1-strict.dtd xhtml-special.ent
These schema's have been downloaded from w3c. However these schemas would
not compile yielding the error wfc_PEs_In_Internal_Subset. I would have
expected these well established w3c schemas to compile with xmerl.
What am I doing wrong?
Tony Wallace
6> B.
[{"http://www.w3.org/1999/xhtml",
"schemas/xhtml1-strict.dtd"},
{"http://www.w3.org/2001/xml-events",
"schemas/xml-events.xsd"},
{"http://www.w3.org/2002/xforms",
"schemas/XForms-Schema.xsd"}]
9> {ok,S1} = xmerl_xsd:process_schemas(B).
3450- fatal: {error,{wfc_PEs_In_Internal_Subset}}
** exception exit: {fatal,{{error,{wfc_PEs_In_Internal_Subset}},
{file,"schemas/xhtml1-strict.dtd"},
{line,628},
{col,89}}}
in function xmerl_scan:fatal/2
in call from xmerl_scan:scan_entity/2
in call from xmerl_scan:scan_markup_decl/2
in call from xmerl_scan:scan_ext_subset/2
in call from xmerl_scan:scan_document/2
in call from xmerl_scan:file/2
in call from xmerl_xsd:process_schemas/2
The 3450 refers to the code line in xmerl_scan:
scan_entity_value("%" ++ _T,S=#xmerl_scanner{environment=prolog},_,_,_,_,_) ->
?fatal({error,{wfc_PEs_In_Internal_Subset}},S);
And the error appears to be associated with line 628 of xhtml1-strict.dtd
The column of 89 would appear suspect as line 628 is not that wide:
621 <!--
622 param is used to supply a named property value.
623 In XML it would seem natural to follow RDF and support an
624 abbreviated syntax where the param elements are replaced
625 by attribute value pairs on the object start tag.
626 -->
627 <!ELEMENT param EMPTY>
628 <!ATTLIST param
629 id ID #IMPLIED
630 name CDATA #IMPLIED
631 value CDATA #IMPLIED
632 valuetype (data|ref|object) "data"
633 type %ContentType; #IMPLIED
634 >
635
If you got this far down the post, many thanks!
Tony
You seem to be invoking xmerl_xsd:process_schemas on a collection of schema documents some of which are XSD schema documents and one of which is not an XSD schema document at all, but a document type definition file (xhtml1-strict.dtd). The process_schemas function expects XSD schema documents, which are XML document instances, but DTD files are not XML document instances. You will need to acquire an XSD schema for XHTML, not the DTD, if you want to do what you appear to want to do. Unfortunately, the XHTML WG's XSD schema documents are not the easiest things in the world to use; good luck.
If you want to work with XForms, you might find it easier to get XSLTForms or Orbeon or BetterForms or EMC Formula working than you did to get backplane.js to work.