Debugging
Stack traces
If there is an error in a RimStone program (such as trying to access invalid memory, negative status that hasn't been checked etc.), or if there's an internal issue (such as a bug in RimStone), a stack trace is created in trace directory (see directories). A single stack trace file is created for each such incident, containing the description of the issue and the file names, function names and line numbers in your source code that led to it. The file names are based on the process-ID of the affected process. There is a limit on how many stack frames RimStone will show this way (from the bottom up) - currently it's 150.
View stack traces
To see errors reported by RimStone (such as trying to access invalid memory, or crashes; but not those from report-error), use -e option of rim to check the stack trace files, which contain the stack along with file names, function names and line numbers. For example, to see the last 3 errors reported:
rim -e 3

Note that function names are decorated; meaning if a request name has a hyphen ("-"), then it is substituted with an underscore ("_") in a function name; if it has a forward slash ("/"), then it is substituted with a double underscore ("__"). For instance, request "request/sub-request" will be internally represented as function "request__sub_request" and will show up like that in a stack trace.
Output from RimStone service without a web server
Use rim (see -r option) to send a request from command line, and receive reply from your services. This is useful in debugging issues and automating tests. For instance, the following will issue a request and receive a reply from your service:
rim -r --req="/my-service" --service --exec

Issues in starting mrim
mrim starts your service process(es). If you're having issues with mrim, check out its log. Assuming your application name is "app-name", the log file is:
$HOME/.rimstone/apps/app-name/.mrimlog

Web server error log
If you are using a web server as a reverse proxy, check its error log, which would store the error messages emitted. Typically, such files are in the following location:
/var/log/<web server>

(for example /var/log/apache2), but the location may vary - consult your web server's documentation.
Using gdb debugger
In order to use gdb debugger, you don't need to do anything special. RimStone itself as well as applications created with RimStone already come with debugging information.

Ultimately, you can attach a debugger to a running RimStone process. If your application name is "app-name", first find the PID (process ID) of its process(es):
ps -ef|grep app-name.srvc

Note that you can control the number of worker processes started, and thus have only a single worker process (or the minimum necessary), which will make attaching to the process that actually processes a request easier (see rim).

Use gdb to load your program:
sudo gdb $HOME/.rimstone/apps/app-name/.bld/app-name.srvc

and then attach to the process (<PID> is the process ID you obtained above):
att <PID>

Once attached, you can break in the request you're debugging:
br <request name>

or in general RimStone request dispatcher:
br rim_dispatch_request

which would handle any request to your application. Request names are decorated to become function names (see above).

Note that by default, gdb will show RimStone code and you can step through it as you've written it, which is easy to follow and understand.

However, if you wish to step through the underlying C libraries, use "--c-lines" option in rim when making your application.
See also
Debugging
debugging  
See all
documentation

Copyright (c) 2019-2025 Gliim LLC. All contents on this web site is "AS IS" without warranties or guarantees of any kind.