1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
<think>
Okay, I'm trying to figure out the category for this bug report. The user provided a detailed problem with steps and code snippets.
First, looking at the description: It's an "Out of memory" issue in hw/omap-dss for ARM. The error happens when g_realloc() tries to allocate too much memory, causing an overflow.
The code involved is in omap_dss.c, specifically around lines where pixels are set and then used to calculate buffer size. Steps to reproduce involve writing certain values via QEMU's qtest interface, leading to a large buffer allocation that exceeds the system's capacity.
The error message from AddressSanitizer mentions that the requested allocation size is way too big, which triggers an abort. This indicates a memory management problem.
Looking at possible categories: Mistranslation relates to incorrect semantic mapping in user-mode assembly, but this issue isn't about that. The problem is with memory allocation, so "other" might seem applicable, but perhaps it's better categorized more precisely.
Possible options include "device", "graphic" since OMAP DSS handles display devices, or maybe "performance" due to the large buffer causing OOM. But in QEMU terms, hw/omap-dss is part of device emulation, especially graphics/display hardware.
The bug occurs when trying to allocate a very large buffer because s->rfbi.pixels becomes an excessively high value, leading to len = pixels * 2 being way too big. This points to an issue with how the RFBI subsystem handles pixel counts and memory allocation for buffers.
So, considering the subsystem involved ( OMAP DSS is related to display devices), it's likely under "graphic". Alternatively, since it's about device-specific hardware emulation, "device" might also be a fit. However, "graphic" seems more specific here as it's about display handling.
</think>
The bug occurs in the graphic subsystem of QEMU, specifically in omap-dss which handles display devices.
graphic
|
