Project Home
Project Home
Discussion Forums
Project Information
Project Info
wiki3613: Debugging_MME (Version 1)

Interaction with the MME#

If you have enabled a log-level of three or higher (see the Table of Debug Commands below) then the MME will log most of the control interactions from its clients. The MME will log to slogger with major code 27 so you can extract it by dumping the whole slog, or by filtering based on this major code:
  sloginfo [-m 27]

The MME will log incoming commands from clients as well as outgoing events. It will not necessarily log return codes, though usually errors will be logged an a lack of error logged can be taken to suggest success. Often the MME will be used in an "asynchronous" mode whereby it will return the function call before completing the requested action, therefor the event(s) that follow a call should be used to determine the state of the MME.

Here is an example of a log:

  Jan 01 00:59:12.879.5 00027 00 MME:io_handle_msg(182): RCV -> MME_IOMSG_TYPE_TRKVIEW_UPDATE
  Jan 01 00:59:12.981.5 00027 00 MME:ntfy_log_event(670): MME_EVENT_TRKSESSIONVIEW_INVALID(48)
  Jan 01 00:59:13.067.5 00027 00 MME:ntfy_log_event(665): MME_EVENT_TRKSESSIONVIEW_UPDATE(48)
  Jan 01 00:59:13.067.5 00027 00 MME:ntfy_log_event(660): MME_EVENT_TRKSESSIONVIEW_COMPLETE(48)

If you are familiar with the MME API it is usually fairly easy to determine which call was made based on the message received. In the above example mme_trksessionview_update() was called. The time when io_handle_msg() logs the "RCV -> MME_IOMSG_TYPE_TRKVIEW_UPDATE" is the time when the MME received this request. We can see that the MME reacted by delivering three events: an MME_EVENT_TRKSESSIONVIEW_INVALID event, followed by an MME_EVENT_TRKSESSIONVIEW_UPDATE and MME_EVENT_TRKSESSIONVIEW_COMPLETE event.

Many of the "unexpected" behaviours of the MME can be explained by studying the interaction of the MME and its client(s). Often it is as simple as an expected call was not made, or an unhandled event was delivered. Even if this isn't the case, seeing how the MME is interacting with the clients is an extremely valuable tool in diagnosing problems.


Table of Debug Commands#

mme-generic -v[vvvvvvvvv]

-D[D]] (additional debug, output to console)

at runtime:
* mme_set_debug()
* mme_get_logging()
* mme_set_logging()

-S (stderr instead of slogger)

at runtime:
* echo setresource verbosity i32 4 ¦ testapp-cmdline -cdebug
io-fs-media -v[vvvv] -dipod,verbose=[1-9],[logfile=/path/to/filename]

at runtime:
* DCMD_MEDIA_CONFIG "verbose=[0-9]"
* DCMD_MEDIA_CONFIG "logfile=/path/to/filename" -dpfs,debug=[1-5]
qdb -v[vvvvvv]

-V (output to console)
mcd -v[vvvvvv]

-V (output to console)

Active Tab Versions Inactive Tab - left sideAssociations Inactive Tab - left sideAttachments Inactive Tab - left sideBack LinksInactive Tab - right side  
    Version From To Version Comment Created By
    Version 2 Added "examining a core file". Ryan Allen(deleted)  -  05/13/2009
    Version 1 Initial. Ryan Allen(deleted)  -  05/12/2009