I've written some code that dumps all ivars of a class into a dictionary in Objective C. This uses valueForKey: to get the data from the class. Sometimes, KVC throws an internal exception that is also captured properly - but this disrupts lldb's feature and all I get is:
error: Execution was interrupted, reason: internal ObjC exception breakpoint(-3)..
The process has been returned to the state before expression evaluation.
There are no breakpoints set. I even tried with -itrue -ufalse as expression options, but it doesn't make a difference. This totally defeats for what I want to use lldb for, and it seems like such a tiny issue. How can I bring clang to simply ignore if there are internal, captured ObjC exceptions while calling a method?
I tried this both from within Xcode, and directly via calling clang from the terminal and connecting to a remote debug server - no difference.
I ran into the same issue. My solution was to wrap a try/catch around it (I only use this code for debugging). See: DALIntrospection.m line #848
NSDictionary *DALPropertyNamesAndValuesMemoryAddressesForObject(NSObject *instance)
Or, if you're running on iOS 7, the private instance method _ivarDescription will print all the ivars for you (similar instance methods are _methodDescription and _shortMethodDescription).
I met the same problem.
My solution is simply alloc init the property before assigning it to the value which caused the crash.
Myself and coworkers ran into this today, and we eventually found a workaround using lldb's python API. The manual way is to run script, and enter:
options = lldb.SBExpressionOptions()
options.SetTrapExceptions(False)
print lldb.frame.EvaluateExpression('ThisThrowsAndCatches()', options).value
This could be packaged into its own command via command script add.
error: Execution was interrupted, reason: internal ObjC exception breakpoint(-3).. The process has been returned to the state before expression evaluation.
Note that lldb specifically points to the internal breakpoint -3 that caused the interruption.
To see the list of all internal breakpoints, run:
(lldb) breakpoint list --internal
...
Kind: ObjC exception
-3: Exception breakpoint (catch: off throw: on) using: name = 'objc_exception_throw', module = libobjc.A.dylib, locations = 1
-3.1: where = libobjc.A.dylib`objc_exception_throw, address = 0x00007ff81bd27be3, unresolved, hit count = 4
Internal breakpoints can be disabled like regular ones:
(lldb) breakpoint disable -3
1 breakpoints disabled.
In case lldb continues getting interrupted you might also need to disable the conditions of the breakpoint:
(lldb) breakpoint disable -3.*
1 breakpoints disabled.
In my particular case there were multiple exception breakpoints I had to disable before I finally got the expected result:
(lldb) breakpoint disable -4 -4.* -5 -5.*
6 breakpoints disabled.
Related
I am getting an error only when the code is entered line by line in the repl. It works when the whole program is pasted at once, or from the command line.
class A {
method a () {
return 1;
}
}
class B {
method b () {
return 2;
}
}
This is the error statement:
===SORRY!=== Error while compiling:
Package 'B' already has a method 'b' (did you mean to declare a multi method?)
This screen shot might make it clearer. On the left I just pasted the code, and on the right I entered it line by line. The code is still working but what is causing the error?
For some reason, I could not reproduce this using just one class.
I can reproduce that error, and looks like a REPL bug, or simply something the REPL is not prepared to do. This, for instance, will also raise an exception:
class A {
method a() {
return 1;
}
};
class foo {
has $.bar = 3;
};
In either form, either pasting it directly or in pieces. It's always the second class. It's probably related to the way EVAL works, but I really don't know. At the end of the day, the REPL can only take you so far and I'm not totally sure this is within the use case. You might want to use Comma or any other IDE, like emacs, for anything that's more complicated than a line; Comma also provides help for evaluating expressions, and even grammars.
I think Comma is the bees knees. And I almost never use the repl. But I enjoy:
Golfing Your example is a more than adequate MRE. But I love minimizing bug examples.
Speculating I think I can see what's going on.
Searching issue queues Rakudo has two issue queues on GH: old and new.
Spelunking compiler code Rakudo is mostly written in Raku; maybe we can work out what this problem is in the REPL code (which is part of the compiler)?
Golfing
First, the bug:
Welcome to 𝐑𝐚𝐤𝐮𝐝𝐨™ v2021.03.
Implementing the 𝐑𝐚𝐤𝐮™ programming language v6.d.
Built on MoarVM version 2021.03.
To exit type 'exit' or '^D'
> # 42
Nil
> { subset a
*
===SORRY!=== Error while compiling:
Redeclaration of symbol 'a'.
at line 3
------> <BOL>⏏<EOL>
Commentary:
To get on the fairway, enter any line that's not just whitespace, and press Enter.
Pick the right iron; open a block with {, declare some named type, and press Enter. The REPL indicates you're on the green by displaying the * multi-line prompt.
To sink the ball, just hit Enter.
Second, golfing in aid of speculation:
> # 42
Nil
> { BEGIN say 99
99
* }
99
>
(BEGIN marks code that is to be run during compilation as soon as the compiler encounters it.)
Speculating
Why does the initial # 42 evaluation matter? Presumably the REPL tries to maintain declarations / state (of variables and types etc) during a REPL session.
And as part of that it's presumably remembering all previous code in a session.
And presumably it's seeing anything but blank lines as counting as previous code.
And the mere existence of some/any previous code somehow influences what state the REPL is maintaining and/or what it's asking the compiler to do.
Maybe.
Why does a type declaration matter when, say, a variable declaration doesn't?
Presumably the REPL and/or compiler is distinguishing between these two kinds of declaration.
Ignoring the REPL, when compiling code, a repeated my declaration only raises a warning, whereas a repeated type declaration is an error. Quite plausibly that's why?
Why does a type declaration have this effect?
Presumably the type successfully compiles and only after that an exception is thrown (because the code is incomplete due to the missing closing brace).
Then the REPL asks the compiler to again try to compile the multi-line code thus far entered, with whatever additional code the user has typed (in my golf version I type nothing and just hit Enter, adding no more code).
This repeated compile attempt includes the type declaration again, which type declaration, because the compilation state from the prior attempt to compile the multi-line code is somehow being retained, is seen by the compiler as a repeat declaration, causing it to throw an exception that causes the REPL to exit multi-line mode and report the error.
In other words, the REPL loop is presumably something like:
As each line is entered, pass it to the compiler, which compiles the code and throws an exception if anything goes wrong.
If an exception is thrown:
2.1 If in multi-line mode (with * prompt), then exit multi-line mode (go back to > prompt) and display exception message.
2.2 Else (so not in multi-line mode), if analysis (plausibly very basic) of the exception and/or entered code suggests multi-line mode would be useful, then enter that mode (with * prompt). In multi-line mode, the entire multi-line of code so far is recompiled each time the user presses Enter.
2.3 Else, display exception message.
(Obviously there's something else going on related to initialization given the need to start with some evaluation to manifest this bug, but that may well be a completely distinct issue.)
Searching
I've browsed through all open Rakudo issues in its old and new queues on GH that match 'repl'. I've selected four that illustrate the range of difficulties the REPL has with maintaining the state of a session:
REPL loses custom operators. "Interestingly, if a postfix operator like this is exported by a module which is loaded by the REPL, the REPL can successfully parse that operator just once, after which it will fail with an error similar to the above." Is this related to the way the bug this SO is focused on doesn't manifest until it's a second or later evaluation?
Perl6 REPL forgets the definition of infix sub. Looks like a dupe of the above issue, but includes extra debugging goodies from Brian Duggan. ❤️
REPL messes up namespaces when Foo is used after Foo::Bar.
In REPL cannot bind to scalars declared on earlier lines.
One thing I haven't done is checked whether these bugs all still exist. My guess is they do. And there are many others like them. Perhaps they have a somewhat common cause? I've no idea. Perhaps we need to look at the code...
Spelunking
A search of the Rakudo sources for 'repl' quickly led to a REPL module. Less than 500 lines of high level Raku code! \o/ (For now, let's just pretend we can pretty much ignore digging into the code it calls...)
From my initial browser, I'll draw attention to:
A sub repl:
sub repl(*%_) {
my $repl := REPL.new(nqp::getcomp("Raku"), %_, True);
nqp::bindattr($repl,REPL,'$!save_ctx',nqp::ctxcaller(nqp::ctx));
$repl.repl-loop(:no-exit);
}
Blame shows that Liz added this a couple months ago. It's very tangential to this bug, but I'm guessing methods and variables with ctx in their name are pretty central to things so this is hopefully a nice way to start pondering that.
method repl-eval. 30 lines or so.
REPL: loop { ... }. 60 lines or so.
That'll do for tonight. I'll post this then return to it all another day.
I'm wondering if LLVM fatal errors are really "fatal" - ie. they invalidate the entire state of the system and are not recoverable.
For example (I'm using the llvm-c interface), the default behavior of the following code:
LLVMMemoryBufferRef mb = LLVMCreateMemoryBufferWithMemoryRange(somedata, data_length, "test", 0);
LLVMModuleRef module;
if (LLVMParseBitcode2(mb, &module) != 0) {
fprintf(stderr, "could not parse module bitcode");
}
is that if the pointer somedata points to invalid bitcode, the fprintf is never executed, but instead the entire process aborts with its own fatal error message on stderr.
However, there is supposedly an interface to catch such errors: LLVMFatalErrorHandler. However, after installing an error handler, the process still just aborts without calling the error handler.
The documentation in LLVM is very poor overall, and the C interface is barely documented at all. But it seems like super-fragile design to have the entire process abort in a mandatory way if some bitcode is corrupt!
So, I'm wondering if "fatal" here implies, as usual - that if such an error occurs, we may not recover and continue using the library (for example trying some different bitcode or repairing the old one, for example), or if it is not really a "fatal" error and we can have the FatalErrorHandler or some other means of catching and notify, or take other remediating actions, and continue the program.
Ok, after reading through the LLVM source for 10+ hours and enlisting the help of a friendly LLVM dev, the answer here is that this is not in fact a fatal error, after all!
The functions called above in the C interface are deprecated and should have been removed; LLVM used to have a notion of "global context", and that was removed years ago. The correct way to do this - so that this error can be caught and handled without aborting the process - is to use the LLVMDiagnosticInfo interface after creating an LLVMContext instance and using the context-specific bitcode reader functions:
void llvmDiagnosticHandler(LLVMDiagnosticInfoRef dir, void *p) {
fprintf(stderr, "LLVM Diagnostic: %s\n", LLVMGetDiagInfoDescription(dir));
}
...
LLVMContextRef llvmCtx = LLVMContextCreate();
LLVMContextSetDiagnosticHandler(llvmCtx, llvmDiagnosticHandler, NULL);
LLVMMemoryBufferRef mb = LLVMCreateMemoryBufferWithMemoryRange(somedata, data_length, "test", 0);
LLVMModuleRef module;
if (LLVMGetBitcodeModuleInContext2(llvmCtx, mb, &module) != 0) {
fprintf(stderr, "could not parse module bitcode");
}
The LLVMDiagnosticInfo also carries with it a "severity" code that indicates the seriousness of the error (sometimes mere warnings or perfomance hints are returned). Also, as I suspected, it is not the case that failing to parse bitcode invalidates the library or context state.
The code that was aborting with the cruddy error message was just a stop-gap to let legacy apps which still called the old API functions work - it set up a context and a minimal error handler which behaves in this way.
in Mopub-SDK for iOS.there is an error in calling "mp_safe_block" method.
Macro definition:
// Macros for dispatching asynchronously to the main queue
#define mp_safe_block(block, ...) block ? block(__VA_ARGS__) : nil
Called as:
mp_safe_block(complete, NSError.sdkInitializationInProgress, nil);
Error message:
Left operand to ? is void, but right operand is of type 'nullptr_t'
maybe this error has nothing to do with the SDK itself. how to fix it ?
PS:
that sdk code run correctly in a new xCode project created by myself. but there is an error in a Xcode-project builded by MMF2(clickTeam fusion)
and this xCode-project version is too old. I updateded setting of Xcode.but it still an error.
My end goal is to modify an Objective-C program's symfile in LLDB. I want to augment the method names so a new, unique name can be used to reference an existing method in the debug symbol file.
For example, if there is a method named -[Foo bar], I can of course break on this method using (lldb) b -[Foo bar], however, I want to create an "alias" for this method named -[Foo baz], so when I execute the following in lldb:
(lldb) b -[Foo baz]
A breakpoint will get set on the address at:
method_getImplementation(class_getInstanceMethod([Foo class], #selector(bar)))
My current method of solving this is to use the dsymutil function to dump the symfile:
dsymutil /path/to/executable -o dump.dYSM
From there, I can use the dwarfdump command to prettify the output into something I can actually edit.
dwarfdump dump.dYSM/Contents/Resources/DWARF/ExecName
Now I can easily edit the AT_name property which contains -[Foo bar]
However, I don't know how to regenerate the dYSM after I have the debug info in this "prettify" format.
Provided I can regenerate the edited dYSM, I am hoping to stick it back into LLDB using either:
(lldb) target modules add or (lldb) target symbol add
So my questions are:
Is there a better way to go about this? Note that I do not have the source nor the object files to regenerate a new dYSM.
Is there a Terminal command that can patch up my edited dwarfdump for me into a LLDB readable debug symbol file?
Cheers!
I'm not entirely clear what you are trying to achieve. It sounded at first like you were trying to break on the dynamically determined implementation of some class/selector pair, in which case you can just do:
(lldb) break set -a `(void *) method_getImplementation((void *)class_getInstanceMethod([Foo class], #selector(bar)))`
Note, you'll have to do this after you've run your program and hit a breakpoint, but then you won't know the specific implementation that's going to get called until you run anyway, so this isn't much of a restriction.
But just munging the name in the DWARF wouldn't have actually achieved this effect. So maybe if you say a little more about your actual aims we can be of more help.
As to question 2, there are no tools to edit dSYM DWARF content after the fact. That's not something there's been much call for.
I have this code:
id error;
// a bunch of stuff, including using error
Finalization finalization = ^(int status) {
id error; // <--- Declaration shadows a local variable
// a bunch of stuff, using error
}
// a bunch of stuff, using error
I use GCC_WARN_SHADOW because it's what I want in every case in my code except this one. In this case, it gives me a warning that I want to suppress.
Is there a way to suppress this one shadow warning without turning off GCC_WARN_SHADOW or renaming the inner error to something else? Some way to mark that declaration of error?
I'm using clang with Xcode 4, if it matters.
First, as a matter of opinion, it's really bad karma to shadow a local variable within an inner block (its bad enough shadowing a global variable in a function). Now "error" can take two different values within a function, and until whomever is reading your code figures it out, they will bang their head quite incessantly. I have seen this issue in real life among paid professionals developing apps. I really suggest renaming the inner error variable.
Answering your question, you can use the GCC/clang compiler pragma to suppress a warning.