SIM card related Projects » SIMtrace 2

Unfortuantely this issue has not been updated with the progress. A patch was developed and submitted as https://gerrit.osmocom.org/#/c/simtrace2/+/16097/ to gerrit. The gerrit issue also unfortunately fails to state Closes: OS#4251 in ist commit log message.

However, we have had user reports of still encountering OOM errors, so I'm keeping this issue open meanwhile.

In the related logs of the user, we get many instances of

-E- ep 2: usb_buf_alloc_st EOMEM (queue already empty)

this is odd, as it raises the question where those buffers are used, if
they are not in the transmit queue.

as well as many more of

-E- _talloc_zero() out of memory!

So I guess some deeper debugging is required in terms of what's happening here.

list of heap allocations in st2 firmware as of 0.6.1

• only use appears to be libosmocore msgb code
• only caller of msgb_alloc() is usb_buf_alloc()
• usb_buf_alloc() callers
  • libcommon/source/card_emu.c
  • libcommon/source/host_communication.c
    • usb_refill_from_host() [for OUT EP]
  • libcommon/source/mode_cardemu.c
    • flush_pts()
    • add_tpdu_byte()
    • send_tpdu_header()
    • card_emu_report_status()
  • libcommon/source/sniffer.c
    • usb_send_data()
    • usb_send_fidi()
    • usb_send_change()

So all in all, it seems extremely simple, as there are not many allocation/free paths. Especially if one only looks at cardem.

I've just observed this bug for the first time on my desk. Still not sure how to reproduce it, but will investigate further.

It seems related to the firmware being out of normal operational mode (i.e. no bidirectional sim card emulation with the host program running).

• buffers are allocated both for receiving data from the host (OUT endpoint) and for data to the host (IN endpoint)
• the new buffer recycle logic is only executed when allocating buffers in IN direction

This means that all memory can be eaten up by pending IN transfers, with the firmware unable to allocate any buffer for receiving data from the host on the OUT endpoint. My original suggested solution of using timer/age information and releasing buffers queued for too much time would have properly solved the problem and prevented this new problem of IN buffers starving OUT buffers.

• https://gerrit.osmocom.org/#/c/simtrace2/+/16575/
• https://gerrit.osmocom.org/#/c/simtrace2/+/16580/
• https://gerrit.osmocom.org/#/c/simtrace2/+/16585/
• https://gerrit.osmocom.org/#/c/simtrace2/+/16584/

patches merged. I'd be very surprised if there were any memleaks left after detailed audit + testing.