Why aren't exceptions being caught?

[christophersanborn]

This one will require some investigation.

Basically, exceptions are only being caught in the APDU ingestion phase. Exceptions that I throw during deserialization and display phases are simply being ignored, and are not aborting processing as they should be.

Will need to understand how the exceptions are being implemented, and what sort of initialization or other steps I'm missing that are turning my THROWs into NOPs.

[christophersanborn]

Chart of where exceptions are being thrown, and where they're not:

Methodology: Putting:

PRINTF("THROW TEST\n");
THROW(EXCEPTION)

in various places and seeing if they cause an abort, as they should, (and if we get the printf output).

Note that processTx is where the TRY, CATCH block is set up. So anything below that in the call stack we expect to handle the throw's correctly.

Call Stack:	Unit:	THROW	PRINTF	Status
...:handleSign (prior to UX_DISPLAY)	main.o	✅	✅	6801
...:handleSign (after UX_DISPLAY)	main.o	❌	❌	freezes
...:handleSign:processTx (before TRY block)	bts_stream.o	✅	✅	6801
...:handleSign:processTx (in TRY block)	bts_stream.o	✅	✅	6a80
...:handleSign:processTx (after TRY block)	bts_stream.o	✅	✅	6801
...:handleSign:processTx:processTxInternal	bts_stream.o	✅	✅
...:handleSign:processTx:processTxInternal: tryTlvDecode	eos_utils.o	✅	✅
...:handleSign:processTx:processTxInternal: processOperationIdField	eos_utils.o	✅	✅

Call Stack:	Unit:	THROW	PRINTF	Status
...:ui_approval_prepro:printArgument: parseLimitOrderCancelOperation: deserializeBtsOperationLimitOrderCancel: deserializeBtsVarint48Type	bts_t_varint.o	❌	✅	Whoa! tight loop. maybe bad imp tho. Evidently does throw. Need to find where caught, prolly mishandled there.

OK, so problem seems to be that we need to wrap the display code found in ui_approval_prepro in a TRY, CATCH block. Although it would seem that ui_approval_prepro is below sample_main in the call stack, the TRY, CATCH block established there is evidently NOT in effect. (And I don't know really what is going on with the call stack there anyway, ui_approval_prepro is call-back function being called either from BOLOS or from an SDK function. How we get there from sample_main is not entirely clear.)

Tested by wrapping the code in a TRY and putting the following catch inside the if (display) block in ui_approval_prepro:

          CATCH_ALL {
            G_io_apdu_buffer[0] = 0x90;
            G_io_apdu_buffer[1] = 0x00;
            // Send back the response, do not restart the event loop
            io_exchange(CHANNEL_APDU | IO_RETURN_AFTER_TX, 2);
            // Display back the original UX
            ui_idle();
          }

and this achieved:

1. Returning back to top-level Menu Ready screen. (This is achieved by ui_idle(). However with only that the device will be frozen at Ready screen and won't take another Tx. (I forget exact details of failure.))
2. Sending a status word back on the APDU so the host comm process will exit. (This is the other stuff).

However, there's something still missing. Because the next Tx to be sent from host computer will immediately fail. There is no debugging output, so I do not know where it is failing. However, the Tx AFTER THAT will go through. So there is something in the "regular" reset process that is not being included here. More tinkering needed.

[christophersanborn]

Tidbits discovered during investigation of above:

• Function ui_idle() (defined in main.c) is what initializes the app's top-level menu ("Use wallet to view accounts"). It is called at program outset from main() (prior to sample_main()), and, as the last statement of all the button handlers that "conclude" a user interaction. (i.e. "confirm" or "cancel" for a Tx signature.) This is the function that brings us back to the main menu screen. It does not bring us back to function main() nor reset any context variables. In fact, we simply continue the APDU loop in sample_main(). (But if we need to reset any context variables... this might be a good place to do it. From a UX perspective this is where we go back to square one. This function might be misnamed.)

• Function sample_main() (called from main(), defined in main.c) never returns. (Except perhaps in extremely extraordinary circumstances — it looks like a THROW(EXCEPTION_IO_RESET) could bring us back up to main(), (possibly thrown as a result of a wake from sleep), but everything else is caught and put on the APDU buffer in sample_main()...) So we just loop here forever, essentially. Even across servicing of multiple user requests.

• OS-provided io_exchange() called from sample_main() does some magic, and, at least some of the time (or probably all the time) is where the "event loop" is managed. For example, the main menu screen won't actually appear on screen until the first time this runs. This function sits and waits for APDU input during the APDU read phase (it may loop through a few times if the APDU is long) and returns quickly when USB data is there to be read. After we finish ingesting the APDU request, handleSign() sets the IO_ASYNCH_REPLY flag and then when we enter io_exchange() again it won't be waiting for input, but also won't exit until a reply has been sent (e.g. when user confirms). Some details still fuzzy. But while we are "waiting" in this function at this stage is when all the UI stuff is displayed on screen, e.g. the transaction deserialization and display. io_exchange is basically orchestrating an event loop, I think, and this is where calls to io_event() (defined in main.c) originate from. These events may include button presses, "ticker" events, etc. Again, this part still fuzzy so confirm anything written here.