<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
Hi Nicolas.<div><br></div><div>> <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">IMO, if we decompile a block, we might want to find the temp names</span></div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> from the method source, but if we decompile a method, what's the</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> point???</span><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Hmm.. aren't there several "layers" of source code possible in a method trailer? See CompiledMethodTrailer class >> #trailerKinds. Even if you have to decompile a method, temp names might still be available from somewhere.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel</span></div><div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 15.04.2021 02:02:36 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">my snippet for inspecting (part of) the stack:<br><br>| tmp list i |<br>tmp := sender.<br>list := Array new: 200.<br>i := 0.<br>[tmp sender == nil]<br> whileFalse: [<br> list atWrap: (i := i+1) put: tmp.<br> tmp := tmp sender].<br> ^{list. i}<br><br>The stack was only about 150,000 deep, but our tools do not really<br>scale at this depth...<br><br>Le jeu. 15 avr. 2021 à 01:57, Nicolas Cellier<br><nicolas.cellier.aka.nice@gmail.com> a écrit :<br>><br>> Hi all,<br>> with the new exception handling, I have encountered some recursive error.<br>> Very hard to debug because the stack grows too fast.<br>> The origin is when trying to browse revisions of a removed method.<br>> I have a:<br>><br>> MethodReference >>timestamp<br>> receiver: a MethodReference Parser >> #externalFunctionDeclaration<br>> UndefinedObject(Object)>>doesNotUnderstand: #timeStamp<br>> ...<br>> Debugger class>>openOn:context:label:contents:fullView:<br>> ...<br>> SmalltalkImage>>logError:inContext:to:<br>> ...<br>> Context>>printDetails:<br>> ...<br>> [] in Context>>printDetails:<br>> Context>>tempsAndValuesLimitedTo:indent:<br>> Context>>tempNames<br>> Context(InstructionStream)>>debuggerMap<br>> CompiledMethod>>debuggerMap<br>> receiver: (MCRepository class>>#browseMethodRevisionsService "a<br>> CompiledMethod(2459914)")<br>> receiver isInstalled ==> false !!! (because I did recompileAll at one point)<br>> DebuggerMethodMap class>>forMethod:<br>> ...<br>> CompiledMethod>>methodNode<br>> [source]: a Text for 'Vw6ilbntYC3Kf9Bz3g3T3YJ+J74W7Mmk9gPb...<br>> note that the source is broken, I don't know where it comes from,<br>> the compiledMethod is not installed...<br>> this context will catch SyntaxErrorNotificationSignal<br>> ...<br>> Parser>>parseCue:noPattern:ifFail:<br>> this context will catch ReparseAfterSourceEditing<br>> ...<br>> SyntaxErrorNotification(Exception)>>signal<br>> expected, the source is broken...<br>> ...<br>> Context>>handleSignal:<br>> Context>>handleSignal:<br>> ^2 consecutive handleSIgnal: here...<br>> the first one (parseCue:noPattern:ifFail:) only catch<br>> ReparseAfterSourceEditing<br>> the second one (methodNode) does catch our SyntaxErrorNotification<br>> on: SyntaxErrorNotification<br>> do: [:ex | ex return: self decompileWithTemps]<br>> ...<br>> CompiledMethod>>decompileWithTemps<br>> oh but this one tries to get the tempNames by parsing the source!<br>> let's go for a cycle...<br>> ...<br>> Parser>>parseCue:noPattern:ifFail:<br>> this context will catch ReparseAfterSourceEditing<br>> ...<br>> SyntaxErrorNotification(Exception)>>signal<br>> Context>>handleSignal:<br>> Context>>handleSignal:<br>> Context>>handleSignal:<br>> ouch, I have 3 of them now<br>> what happens? it's all normal, I now have 2 parseCue:... in the<br>> stack catching ReparseAfterSourceEditing<br>> the 3rd is catching SyntaxErrorNotification and retries parsing tempNames...<br>> and we're back to another cycle.<br>> ...<br>> tada, there's more than 1000 handleSignal: in the stack when I<br>> interrupted the process, and it's impossible to debug, and I thought<br>> the new exception handling had a problem...<br>> It doesn't so far.<br>> We have another problem with broken source for an uninstalled<br>> CompiledMethod, that tries to decompile using broken source...<br>><br>> I'm happy that I'm not the root cause, but this is most annoying.<br>> IMO, if we decompile a block, we might want to find the temp names<br>> from the method source, but if we decompile a method, what's the<br>> point???<br><br></nicolas.cellier.aka.nice@gmail.com></div></blockquote></div>