Importing from XCode 10.1 Instruments fails

[crespoxiao]

hi,
when I run in command line $ speedscope Instruments3.trace
Error: EISDIR: illegal operation on a directory, read
Usage: speedscope [filepath]
If invoked with no arguments, will open a local copy of speedscope in your default browser.
Once open, you can browse for a profile to import.
If - is used as the filepath, will read from stdin instead.
cat /path/to/profile | speedscope -

if I use browser, got the error below:
Unrecognized format! See documentation about supported formats.

please let me know when you fix it.
Thank you !

[bjorn3]

Error: EISDIR: illegal operation on a directory, read

Instruments3.trace seems to be a directory. It is probably a bundle (a dir which finder shows as a file, just like .app) Looking at the wiki, instruments files don't seem to be supported.

[jlfwong]

Hi @crespoxiao and @bjorn3!

Re: it being a directory, that part is a known issue, though one that's fixable.

Instruments file in general are supported, though only when dropped onto the browser: https://github.com/jlfwong/speedscope/wiki/Importing-from-Instruments.app

Re: Instruments 10 support not working, can you provide a profile that fails to import when it's dropped onto the browser? This was reported in the past here: #163, but I couldn't reproduce the problem.

[zintus]

Thanks for awesome app, @jlfwong !

I'm able to create trace file which reproduce import problems:

1. Stacktraces are messed up
2. Thread ids are incorrect (they don't match binary plist entries)

Latter suggests that something changed either in bulkstore or in integeruniquer.data. After doing someresearch i'm out of ideas what may be wrong with them, as overall structure looks same as you described in blog post.

Please see compressed trace file test.trace.zip

[jlfwong]

@zintus Thanks for providing the test file! The import definitely looks wrong.

I started investigating, and have the code I've attempted in #216, but I'm not happy with the fix, and it still seems pretty wrong. I don't have a ton of time to work on issues like these, and diagnosing problems here is pretty slow going and frustrating, so I'm not going to commit to any kind of permanent fix here. Hopefully the code in that PR may be useful guidance to someone else who wants to dig into it. I'll update this issue if I do start looking into it again.

The timestamps being incorrect is pretty confusing. I tried reading the timestamps as 64bit instead of 48bit, but then the timestamps are out of order, which would be really surprising to me.

It looks like the only other Instruments 10 import I've tried (added in #203) also has incorrect durations after import into speedscope. So something is wrong. (CC @Archerlly since I'm guessing you might've been using the import results from Instruments 10?)

Here's an example of the displayed results from Instruments being totally different from the displayed results in speedscope