I/O error (write failure) on Firefox Android

[siddhpant]

Binary: https://github.com/JonathanSalwan/binary-samples/blob/master/elf-Linux-x64-bash

WARNING: write(rz_cons_instance.fdout, buf, len) at ../librz/cons/cons.c:165 failed: I/O error

(Used desktop mode since the UI isn't responsive.)

[IndAlok]

@siddhpant Thanks for raising the issue. Could you check once, if the issue persists after the PR, as it doesn't seem to be, on my side. (attached ref.)
There are a few todo's related to this, that I've kept in mind, and would gradually work on, including better visibility on mobile browsers, an option to save the modified binary, etc.
Additional suggestions would be great.

[siddhpant]

Thanks, it shows up now!

Though the disas and graph tabs don't seem to work, clicking on a function does nothing. Maybe it is just "loading" for long? Should show a loading icon or msg in that case.

Enabling cache and then trying again shows that those weren't saved (assuming cache saves the parsing). The CLI still works though.

Also, if the cache option saves the parsing, it should allow directly clicking the filename from the homepage it shows instead of "re-uploading" (it's not uploaded but ykwim). You can show the hash for discerning.

[IndAlok]

Thanks, it shows up now!
Though the disas and graph tabs don't seem to work, clicking on a function does nothing. Maybe it is just "loading" for long? Should show a loading icon or msg in that case.

Yes, that's the case with "larger" binaries (in terms of dissassembly). The current limitation is of non-persistance of state for the GUI functions. Everytime a function is clicked, a new instance with "aaa" (analysis) chained with the function dissassembly or graph commands is run, to fetch the output to be displayed. This has minimal-to-no effect for smaller binaries, however in this case, the analysis takes considerably longer time, and hence the same amt. of delay with every function dias/graph fetch. This isn't the case with the cli instance. As the binary is <1mb, autoanalysis is performed on loading the binary itself (the delay after initialization), and afterwards we can use the "after-analysis" commands as expected, due to it maintaining the same-state. This is something I've kept on priority to find a workaround.

Enabling cache and then trying again shows that those weren't saved (assuming cache saves the parsing). The CLI still works though.

The assumption might be a misunderstanding here. Enabing cache only keeps the wasm (for now), "Enable I/O cache" hasn't been implemented matching rizin's behaviour, yet. WASM is cached so it doesn't have to fetch everytime afterwards, for new instances. The reason you might be getting same delay "before" and "after" the cache toggle, is primarily due to the autoanalysis delay in the beginning, which is comparatively almost same, in contrast to local instance analysis if done manually...

Also, if the cache option saves the parsing, it should allow directly clicking the filename from the homepage it shows instead of "re-uploading" (it's not uploaded but ykwim). You can show the hash for discerning.

Yeah, the cache doesn't save the parsing (for now atleast). What are your thoughts on it? Do you think saving for parsing should then be globalized for all binaries user "uploads"? As the local history of files maintained, shows up all the files, and not only the ones that user (in future) might have saved parsing of. So the "onClick" behaviour for the ones, where the parsing hasn't been saved, should be loading it normally as it does now, and perform autoanalysis accordingly with size filter (< or > than 1mb)?

We can just keep this issue open I think. Would gradually be working on things discussed, as time allows.

[siddhpant]

The current limitation is of non-persistance of state for the GUI functions. Everytime a function is clicked, a new instance with "aaa" (analysis) chained with the function dissassembly or graph commands is run, to fetch the output to be displayed.

This should be mentioned in a red alert box at the top if the binary is "large" or a timeout is encountered.

Honestly, when a binary is "uploaded" and it is loading, all analysis for all functions should be done at that stage for the least amount of surprises. Maybe an "unlazy" switch?

Do you think saving for parsing should then be globalized for all binaries user "uploads"?

Yes, parsing should be really be saved for a given binary hash. It just makes sense.