tencent cloud

Tencent Cloud Observability Platform

DocumentationTencent Cloud Observability PlatformTerminal Performance Monitoring ProConsole Operation GuideData AnalysisAttachment

Attachment

Download
Focus Mode
Font Size
Last updated: 2026-05-25 18:53:29
The attachments provide on-site abnormal data in file format, containing two types of data: platform-default collected data and business-custom collected data.

Feature Introduction

In the case details on the platform, the attachment Tab displays all attachments for the current exception case. Users can click to view attachment contents online. Users can also click Compress and download to download all attachments for the current case.


Export in batches

Supports the feature of batch exporting case attachments. Click the download icon on the left > Export Attachment, select the attachments to be downloaded, then click OK, as shown in the figure below:


Search attachments

Users can use the attachment filter option to search for cases containing specified attachments. When multiple attachments are selected, it represents an OR relationship, filtering out exception cases that contain any of the following attachments.


Upload Custom Attachments

Android
iOS
Businesses can use the custom attachment upload API exposed by the SDK to supplement additional on-site business data in the form of attachments.
Custom attachments are supported starting from Android SDK version 4.3.0.3.
Using this API requires initializing both the SDK performance and SDK quality modules. For details, see the SDK Access Guide.
The size limit for custom files after compression is 10 MB. If the size exceeds this limit, the file will be deleted directly and will not be uploaded.
This API can be called multiple times, and subsequent calls will override the values set previously.
CrashReport.setAdditionalAttachmentPaths(String[] files);
Custom files are uploaded only during the next startup.
The SDK disables this feature by default. To enable it, add the following configuration on the Portal side.

After the next startup, you can check the "sub_type: custom_log" keyword logs to confirm whether custom files have been uploaded.
12-07 20:42:26.673 15758 15862 I RMonitor_report_File: url: https://rmonitor.qq.com/v1/2ff6123857/custom/upload-file?sign=22efd184a95c12d7faaecb8e8edc3266&timestamp=1670416946671&nonce=ee48217de804345e1634d0adf58e8825, sub_type: custom_log
Support for custom attachments is available starting from iOS SDK version 2.7.51.
Refer to the following code to set the path for custom attachments. After an exception occurs, the attachments will be packaged and uploaded from the corresponding directory.
/**
 * Set the collection of determined paths for custom files.
 * The compressed file must not exceed 10 MB and will be uploaded on the next startup.
 */
+ (void)setAdditionalAttachmentPaths:(NSArray<NSString *>*)pathArray;

Usage example:
[RumPro setAdditionalAttachmentPaths:[NSArray arrayWithObject:filePath]];
Custom files are uploaded only during the next startup.
The SDK disables this feature by default. To enable it, add the following configuration on the Portal side.
Calling this API when a crash occurs will not take effect. You need to set the file paths in advance.
If you do not see the custom file option in the current configuration, click the plus icon on the far right of the last configuration item to add a custom file configuration item.


Android

The following content mainly introduces the information recorded for each file in the Attachments Tab of Android reported case details and the meaning of each piece of information.

Attachments Overview

Classification/Tab
Source
error stack
Exported in the attachment "crash.log" from the crash details API.
tombstone
From attachment tomb.zip
Crash Context / Basic Information
Exported to the attachment "detail_data.JSON" from the crash details API.
Crash Context / Custom Fields
From attachment "valueMapOthers.txt"
Crash Context / Page Tracking
From attachment martianlog.txt
Logs
From attachment log.txt
FD Information
From attachment crashInfos.txt
Process Information
From attachment state_file.zip
Information supplemented via the callback API getCrashExtraData
From attachment extraMessage.txt
Information supplemented via the callback API getCrashExtraMessage
Exported in the attachment user_datas.log
The content configured via CrashReport.putUserData and setUserSceneTag
Exported in the attachment valueMapOthers.txt
ANR_INFO
From attachment anrMessage.txt
ANR_Trace
From attachment trace.zip

crash.log

Stores error stack information, including the stack of the current exception thread and the stacks of other threads, consistent with the content displayed in the Error Stack Tab.

Why there are two different stacks for the crashed thread with different process IDs preceding them?
1. For Native exceptions, both the Native stack and Java stack are captured during exception handling at the Native layer, obtaining the process ID at the Native level.
2. The stacks of other threads are treated as additional information, processed at the Java layer, where the JVM stacks are retrieved, and the process ID corresponds to the one described within the JVM.
3. The current stacks of other threads include all JVM thread stacks of the application at the time of the exception, which may also include the currently crashed thread, but do not include threads created at the Native layer.

tomb.zip

Corresponding to the system's "tombstone" file, generated when an application or system process crashes. This file contains critical information at the time of the crash, such as stack traces, memory maps, and register states. The file is generated following the format modeled after the system's "tombstone" file.
tombstone contains the following information sections:
Exception Summary
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Crash type: 'Native'
Start time: '2023-12-22T15:55:39.381+0800'
Crash time: '2023-12-22T15:58:30.119+0800'
App version: '4.4.0-beta.3'RumPro
Rooted: 'No'
API level: '30'
Build fingerprint: 'vivo/PD1824/PD1824:11/RP1A.200720.012/compiler03061748:user/release-keys'
ABI: 'arm64'
pid: 26730, tid: 26730, name: .example.sdkapp  >>> com.example.sdkapp <<<
signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
Abort message: 'JNI DETECTED ERROR IN AppLICATION: jarray was NULL     in call to GetObjectArrayElement     from void com.tencent.RumPro.crashreport.crash.jni.NativeCrashHandler.testCrash()'
Register Information
    x0  0000000000000000  x1  000000000000686a  x2  0000000000000006  x3  0000007fdab30cc0
    x4  00000077f497b000  x5  00000077f497b000  x6  00000077f497b000  x7  000000000042906e
    x8  00000000000000f0  x9  b8ae21afa5964f35  x10 0000000000000000  x11 ffffffc0fffffbdf
    x12 0000000000000001  x13 00000000658541a6  x14 0005e9acbf980fa7  x15 000077c18d549120
    x16 00000077f138b948  x17 00000077f1368630  x18 00000077f3d3a000  x19 000000000000686a
    x20 000000000000686a  x21 00000000ffffffff  x22 000000000000000b  x23 000000000000000b
    x24 000000776caa41c5  x25 0000000000000001  x26 000000776cabb177  x27 000000776d072000
    x28 b4000077f3452340  x29 0000007fdab30d40
    sp  0000007fdab30ca0  lr  00000077f1317d24  pc  00000077f1317d50
Exception Stack
backtrace:
    #00 pc 000000000008cd50  /apex/com.android.runtime/lib64/bionic/libc.SO (abort+164)
    #01 pc 00000000005320a0  /apex/com.android.art/lib64/libart.SO (_ZN3art7Runtime5AbortEPKc+2340)
    #02 pc 000000000001394c  /system/lib64/libbase.SO (_ZZN7android4base10SetAborterEONSt3__18functionIFvPKcEEEEN3$_38__invokeES4_+76)
    #03 pc 00000000000130cc  /system/lib64/libbase.SO (_ZN7android4base10LogMessageD1Ev+312)
    #04 pc 0000000000369b00  /apex/com.android.art/lib64/libart.SO (_ZN3art9JavaVMExt8JniAbortEPKcS2_+2596)
    #05 pc 0000000000369b78  /apex/com.android.art/lib64/libart.SO (_ZN3art9JavaVMExt9JniAbortVEPKcS2_St9__va_list+108)
    #06 pc 000000000035b7c4  /apex/com.android.art/lib64/libart.SO (_ZN3art12_GLOBAL__N_111ScopedCheck6AbortFEPKcz+144)
    ...
    #81 pc 0000000000088188  /apex/com.android.runtime/lib64/bionic/libc.SO (__libc_init+108)
Build ID
Build ID is a unique identifier generated during the compilation process, used to identify specific binary files. The primary purpose of Build ID is to help developers determine the exact version of the binary file being executed during debugging. In Linux systems, Build ID is typically generated by the compiler or linker during compilation, often as a hash value of source code, compilation options, and other information. If two ELF files share the same Build ID, they are considered identical versions of the library.
build id:
    /apex/com.android.runtime/lib64/bionic/libc.SO (BuildId: 4995223f2954ed2746d96c2f1c7939a1. FileSize: 1314184. LastModified: 2009-01-01T08:00:00.000+0800. MD5: 0eabd0f3735afdc6317062180a4369ec)
    ...
    /system/bin/app_process64 (BuildId: c8e30518cdd6709068b3a08e6bfe4a76. FileSize: 33832. LastModified: 2009-01-01T08:00:00.000+0800. MD5: 68ed3a8e223ff95392828c5b5dd451f3)
On Mac, the Build ID of an SO file can be directly read using the readelf tool.
> readelf -n libNative.SO 

Displaying notes found in: .note.gnu.build-id
  Owner                Data size    Description
  GNU                  0x00000014   NT_GNU_BUILD_ID (unique build ID bitstring)
    Build ID: dae1f4c9f93715c9de15c86161a1af37b5cce24a
Stack Memory
stack:
         0000007fdab30c20  00000077f3814000  [anon:stack_and_tls:main]
         0000007fdab30c28  0000000000000002
         0000007fdab30c30  0000007fdab30d58  [stack]
         0000007fdab30c38  0000000000000000
         0000007fdab30c40  000000776cac3c9e  /apex/com.android.art/lib64/libart.SO
         0000007fdab30c48  00000077f12d0c84  /apex/com.android.runtime/lib64/bionic/libc.SO (malloc+44)
         0000007fdab30c50  00000076f4d262c0  [anon:libc_malloc]
         0000007fdab30c58  b8ae21afa5964f35
         0000007fdab30c60  0000007fdab30d40  [stack]
         0000007fdab30c68  00000077f1317ce8  /apex/com.android.runtime/lib64/bionic/libc.SO (abort+60)
         0000007fdab30c70  000000000000000b
         0000007fdab30c78  000000776cac3c9e  /apex/com.android.art/lib64/libart.SO
         0000007fdab30c80  000000000000000b
         0000007fdab30c88  00000076fd2b9a00  [anon:libc_malloc]
         0000007fdab30c90  00000077f4a797f0  [anon:.bss]
         0000007fdab30c98  00000076f4c6e080  [anon:libc_malloc]
    #00  0000007fdab30ca0  0000000000000001
    ...
    ........  ........
    #81  0000007fdab35f80  0000007fdab35fd0  [stack]
         0000007fdab35f88  0000005e8de33048  /system/bin/app_process64 (main)
         0000007fdab35f90  0000000000000000
         0000007fdab35f98  0000000000000000
         0000007fdab35fa0  0000000000000000
         0000007fdab35fa8  0000000000000000
         0000007fdab35fb0  0000000000000000
         0000007fdab35fb8  0000005e8de37000  /system/bin/app_process64
         0000007fdab35fc0  0000005e8de37010  /system/bin/app_process64
         0000007fdab35fc8  0000005e8de37028  /system/bin/app_process64
         0000007fdab35fd0  0000000000000000
         0000007fdab35fd8  00000077f49caa68  /apex/com.android.runtime/bin/linker64 (__dl__start+8)
         0000007fdab35fe0  0000000000000006
         0000007fdab35fe8  0000007fdab36290  [stack]
         0000007fdab35ff0  0000007fdab362aa  [stack]
         0000007fdab35ff8  0000007fdab362b3  [stack]
Memory near general registers and memory information.

detail_data.JSON

Basic data and page tracking are on-site information automatically captured by the SDK during exceptions, with the basic data exported in the attachment "detail_data.JSON".
The "App Channel" shown in the custom fields comes from the "appInfo" in "detail_data.JSON".


valueMapOthers.txt

Custom fields refer to the Key/Value pairs set by the business through the CrashReport.putUserData API, with the relevant content exported in the attachment "valueMapOthers.txt".
The tags configured via the CrashReport.setUserSceneTag API are exported in the attachment "valueMapOthers.txt".
The "App Channel" shown in the custom fields comes from the "appInfo" in "detail_data.JSON".
The content displayed in the custom fields section of the on-site data is consistent with the attachment "valueMapOthers.txt".

martianlog.txt

Page tracking data from the period before the exception occurred is automatically recorded by the SDK.
This data is also displayed in on-site data > Page tracking sections.

log.txt

The system logs displayed in the Log Tab of the exception scene correspond to the attachment "log.txt".


crashInfos.txt

The FD information displayed in the FD Tab of the exception scene comes from the attachment "crashInfos.txt".
In addition, the attachment "crashInfos.txt" also contains System SO info, with information sourced from the "/proc/$pid/maps" file.
System SO infos:
  707dd000-70a50000 r-xp 00080000 fc:00 171                                /apex/com.android.art/Javalib/arm64/boot.oat
  70a65000-70ab7000 r-xp 00010000 fc:00 165                                /apex/com.android.art/Javalib/arm64/boot-core-libart.oat
  ...
Taking the first line as an example, this information describes the SO file's location in memory, access permissions, offset on disk, and other relevant details.
"707dd000-70a50000": This is the address range of the file in memory. It means the file is mapped to memory starting at address 0x707dd000 and ending at address 0x70a50000.
"r-xp": This indicates the access permissions of the file in memory. Here, "r" stands for readable, "x" for executable, and "p" for private.
"00080000": This is the file's offset on disk, indicating that the starting position of the file in the disk is offset by 0x00080000 from the beginning of the file.
"fc:00": This represents the device number and inode number of the file, used to uniquely identify the file.
"171": This is the file descriptor of the file, used to identify the file in the operating system.
The stack in tomb.zip also uses this information to identify the SO files corresponding to certain addresses.


state_file.zip

The process information in the exception details comes from the attachment "state_file.zip".
Maps information comes from the file "/proc/$pid/maps".
Meminfo information indicates the memory usage of user processes, showing how the application's current memory is primarily allocated.
Process Status and Thread Status indicate the state metrics of the currently running process and its individual threads, respectively.


user_datas.log

The information supplemented via the callback API getCrashExtraMessage is exported in the attachment "user_datas.log".

extraMessage.txt

The information supplemented via the callback API getCrashExtraData is exported in the attachment "extraMessage.txt".

anrMessage.txt

The information from "anrMessage.txt" is displayed in "ANR_INFO".
ANR_INFO is a system report generated by the application when an ANR occurs, recording the Activity component where the ANR happened, the Process ID of the affected process, and the cause of the ANR.
Load represents the system's average load over 1, 5, and 15 minutes when an ANR occurs. The unit of average load is the number of processes, indicating the average count of processes running or waiting for CPU resources during the ANR. CPU Usage indicates detailed CPU utilization during the ANR timeframe. This information can be used to assist in analyzing ANR issues.


trace.zip

The information from "trace.zip" is displayed in "ANR Trace".
ANR Trace is a log file that contains events and thread stack traces occurring during ANR in the application.
Part 1: ANR Time and GC Information. This section shows the duration of the current ANR issue and the GC operations performed by the system.
Part 2: Thread Stack Information. This section lists stack trace information for all threads running during the ANR. In addition to stack details, each thread entry includes status information such as Thread ID (tid), Thread Priority (prio), Thread State (state), Thread Scheduling Statistics (schedstat), and CPU time used by the thread (utm and stm). Combining this information, especially the thread stack traces, can quickly help pinpoint and analyze the root causes of ANR issues.


iOS

The following content mainly introduces the information recorded for each file in the Attachments Tab of iOS reported case details and the meaning of each piece of information.

Attachments Overview

Logs are currently not supported on the iOS platform.
Classification/Tab
Source
error stack
Exported in the attachment "crash.log" from the crash details API.
Crash Context / Basic Information
Exported to the attachment "detail_data.JSON" from the crash details API.
Crash Context / Custom Fields
From attachment "valueMapOthers.txt"
Crash Context / Page Tracking
From attachment "martianlog.txt"
Information supplemented via the API "setUserValue"
Exported in the attachment user_datas.log
Information supplemented via the callback API attachmentForException
Exported in the attachment "crash_attach.log"
Memory Information
Attachment "meminfo.txt"

crash.log

Stores error stack information, including the stack of the current exception thread and the stacks of other threads, consistent with the content displayed in the Error Stack Tab.
Stacks of different threads are separated by blank lines, with the first line indicating the thread ID and thread name.
It contains the register information of the current exception thread.
Contains information about all modules.


detail_data.JSON

Basic data and page tracking are on-site information automatically captured by the SDK during exceptions, with the basic data exported in the attachment "detail_data.JSON".
The "App Channel" displayed in the custom fields comes from the "appInfo" in "detail_data.JSON".


valueMapOthers.txt

Contains the content set by the business via the API SetUserValue.
The content displayed in the custom fields section of the on-site data is consistent with the attachment "valueMapOthers.txt".


martianlog.txt

Page tracking data from the period before the exception occurred is automatically recorded by the SDK.
This data is also displayed in on-site data > Page tracking sections.


user_datas.log

Contains the content set by the business via the API SetUserValue.
The content displayed in the custom fields section of the on-site data is consistent with the attachment "user_datas.log".

crash_attach.log

Content set by the business via the callback API attachmentForException.

meminfo.txt

Memory overview information at the time of exception.


Previous Topic: Custom DataNext Topic: FAQs

Help and Support

Was this page helpful?

Help us improve! Rate your documentation experience in 5 mins.

Feedback