Introducing logcat.ai 3.0: source-cited findings, team Spaces, robots and more

Until 3.0, logcat.ai told you what went wrong in a log. Now it also shows you where. A finding on an Android or kernel log now cites the platform source line that printed it, and from that line you can ask for a fix written against the code.

That’s the headline. Below is the rest of 3.0: Spaces for working on captures as a team, deep research reports that open on the verdict, a new log viewer, kernel crashes symbolized to the line, new capture types for robots, vehicles and Wi-Fi, and a dashboard for baseband captures.

From a finding to the source line to a proposed fix#

A finding on a logcat or kernel log now names the platform source file, the line, and what that code does. A Java crash cites the frame in its own stack trace. Click the citation and the code opens beside the finding.

From there you can step outward: the other lines in the same function that log, with how often each one fired in your capture, then what calls the function and what it calls. A capture’s Overview also lists the lines the source says should have appeared alongside your findings and didn’t. That’s often where the answer is.

Where a citation matches an exact line, you can ask for a fix written against that code. You get a summary, the reasoning, a diff, and what to verify before you trust it, and you can watch each file it reads and each call it follows while it works. A crash’s fix is reasoned from the whole call chain and says which frame the change belongs in. We propose, you decide. Nothing is ever applied to your code. Generating a fix draws investigation units, and re-opening one is free. Fixes are asked for in the console, not over the API, though a saved one can be read there.

Source grounding is a research preview. A few limits, so you know what to expect:

• Citations cover Android logs and Linux kernel logs, against the source we hold: recent Android platform releases, the Android common kernels and the Pixel 6 kernel. The References page lists what your account can reach. Network captures, traces, databases, modem logs and an app’s own log are analyzed normally, with no citations, and so are a bugreport’s crash dumps and ANR traces.
• A log is cited only when the version it states matches source we hold exactly. A near miss would name the right file at the wrong line, so you get no citation rather than a wrong one.
• Citations and fixes need source-grounded analysis on your account. Without it, findings arrive exactly as they did before.

Read about source-grounded findings and candidate fixes.

Spaces: your team, on the same captures#

Create a space, add colleagues, and publish a capture into it. Everyone in the space can read it and investigate it. An investigation whose captures are all in the space shows up for everyone on the space’s Investigations tab. Share a bugreport and your colleagues get every log inside it.

Publishing doesn’t move anything. The capture stays yours: only you can rename, delete, re-run or share it onward, and you can withdraw it. Follow-ups a colleague asks are charged to them. Organization owners and admins can open any space, and the space is told when they do.

Spaces live under your organization in the console, so you need to be part of an organization on logcat.ai to use them. Create your first space, and see the changelog for the details.

Deep research reports lead with the verdict#

A finished deep research investigation now opens on its verdict: your question, a confidence pill and the direct answer, then the key figures and the findings ranked by impact. Each finding opens in place with its analysis and tables. Sources and the investigation’s steps sit in a rail beside the report. Hover a source to read the passage it was taken from, and ask follow-ups in the same rail.

The confidence is read from the findings the verdict rests on. A finding whose citations point to nothing the investigation read is marked low, so treat it as a lead to check rather than a result.

A comparison names its captures on the verdict card, pairs their key figures and groups the sources by capture. The shared link and the PDF export match the page. Investigations completed before the new layout keep their previous one.

Read about deep research.

A new log viewer#

Every text log’s Logs tab now opens in a new viewer. Only the lines on screen are loaded, so a file of millions of lines scrolls like a short one. Filter by level, tag, PID or text, and every count updates under your other filters. Jump to a time or a line number.

The density strip above the lines shows where lines cluster and flags spikes. Click to jump there, or drag to narrow to a range. Open any line for its fields, the insights that cite it, and the lines around it.

Save a filter as a view and share it with your workspace. Press B to bookmark a line, and it keeps its mark under any filter. Citations in findings and reports open on the exact line, highlighted. Links saved before, including citations in older reports, still open on the same lines. In a bundle, the Logs tab can show two of its text files side by side on the capture’s clock, moving together.

Read about the log viewer.

Kernel crashes, symbolized to the line#

A kernel crash prints its call chain as function names and offsets. Upload a kernel debug image to References, and the chain resolves to named functions, and to file and line where the image is verified to match the crash’s build. For a driver that isn’t built into the kernel, add its loadable module (.ko) and that driver’s frames resolve too. The chain is drawn on the dashboard, innermost frame first.

Already analyzed the capture? Re-run deeper symbolizes it in place, with no re-analysis and nothing to re-upload.

Uploading a kernel debug image needs kernel crash dump analysis on your account. A loadable module needs nothing extra.

Read about kernel dumps and References.

Robots, vehicles and Wi-Fi#

3.0 adds capture types from outside the phone. Each one uploads exactly as it came off the device.

• Robot recordings. ROS 1 bags, MCAP and ROS 2 database recordings upload directly, with the channel inventory, the time window and the robot’s own logs pulled out. They need robotics log analysis on your account.
• Vehicle bus traces. Vector binary (.blf), Vector ASCII (.asc) and DTS diagnostic (.trc) traces upload as recorded, with no export step. A PCAN-View .trc, which uses the same extension, still needs a text export first; the guide shows how to tell the two apart. Every trace format now finds your registered signal database on its own, so frames read as named signals. They need automotive log analysis on your account.
• Wi-Fi captures. A packet capture taken in monitor mode gets a radio layer: the association sequence, retries, deauthentications, and signal strength where the capture records it. Packet captures in general gain transport-health, ARP and industrial fieldbus analyses.
• Flash crash records. Flash-partition (mtdoops) and pstore/ramoops crash records upload and decode as kernel crashes.

See every supported file type.

Baseband captures get their own dashboard#

A Qualcomm modem capture’s dashboard now opens on its headline numbers and on how much of the capture could be read. Below that: which cell served when, the cells ranked by level, quality or strength, radio performance by family, and signalling messages by name and direction. Charts that hold several views switch between them in place.

A chart the capture has no records for says why rather than disappearing: the records aren’t in the capture, aren’t readable yet, or only part of the capture could be checked. Each record type is marked with whether it’s read, and the readability panel says whether a message database would restore anything. The capture’s Logs tab lists its decoded records on one timeline. Filter them by kind, technology, layer or direction, and open any record for what was decoded from it.

Baseband analysis needs telecom log analysis on your account. Read about modem captures.

Since June#

What shipped in July, in brief:

• Kernel ramdump analysis. Upload a Qualcomm dump archive from a device that crashed hard and get the reset reason, NoC bus faults, DCC hardware registers, the running tasks and CPUs, and the loaded drivers. Add a matching vmlinux to References and the analysis also recovers the kernel log, the userspace logcat and the on-screen framebuffer from memory. It needs kernel crash dump analysis on your account. See kernel ramdumps and References.
• Network captures and Perfetto traces. pcap and pcapng files, btsnoop Bluetooth HCI logs, SQLite snapshots and Perfetto traces are decoded at upload and analyzed as structured data. Quick search and deep research query the records directly and can answer with exact counts, flows and slices. See network captures and Perfetto traces.
• Multi-file bundles. Upload an archive of logs as it is. Each file is analyzed on its own and findings are correlated across the set, so an identifier that means nothing in one file can be resolved from another file in the same upload. See multi-file bundles.
• The public API and webhooks. Upload, poll, fetch a dashboard and search over /api/v1, or subscribe to a webhook and skip the polling. It needs API access on your account. See the developer docs.

Where to go next#

Everything in 3.0 is in the changelog, including the smaller additions and fixes this post skips, such as bugreports now being read all the way down and a much higher size ceiling for dumps and captures. 3.0 is also the release where analysis became metered: uploads and follow-up questions now draw investigation units, so please read the changelog’s Billing section. Each feature has its guide on docs.logcat.ai.

If something looks wrong, write to us at support@logcat.ai.