Showing posts with label debugging. Show all posts
Showing posts with label debugging. Show all posts

Thursday, July 29, 2010

erlang: Simple Debug macro

When testing things I need some quick way to debug "a la" printf() style. Old habits :)

Here's is the simple debug macro I use:
-ifdef(debug).
-define(DEBUG(Format, Args),
  io:format("~s.~w: DEBUG: " ++ Format, [ ?MODULE, ?LINE | Args])).
-else.
-define(DEBUG(Format, Args), true).
-endif.
Write it down in a "debug.hrl" file, then you only need to add this line in any file header:
-include("debug.hrl").
This simple macro gives you the module name and the line number. This saves me a lot of time.

Then you need to define the "debug" atom to let your macro do what you want. The compile:file/2 handles options for this, the syntax is {d, debug}

Saturday, October 13, 2007

LibTre and Posix, the segfault explanation

You already know that I want to make a libTRE driver such as the RE posix driver... But what you may not know is that I've never lost this amount of time debugging things...
I've, for a long long time ago, called 'gdb' my friend to rescue me ...
Let me explain the problem: we want to call 'regcomp' and 'regexec' from the libTRE package. Take your time and reread this sentence:

We want to call 'regcomp' and 'regexec' from the libTRE package.

This seems really easy, but we want to make this from a shared library... A shared library that we will open at runtime.
And lauching our erlang shell make the ld process finds symbols addresses in various .so files for us automagically...

Since I'm using ubuntu, the posix regexp are located in the libc.so.6 library, so ld knows about regcomp and regexec before I can even call 'erl_ddll:load_driver/2'...

Loading the driver into the erlang vm from my freshly built .so file, don't really work as expected... 'regcomp' is still the one from the glibc, and not the one from the libTRE driver...

But 'regex_t' is the one from tre, and 'regcomp' is the one from posix... There definition of the regex_t struct isn't the same :p

The driver structure:

typedef struct _desc {
ErlDrvPort port;
ErlDrvTermData dport; /* the port identifier as ErlDrvTermData */
regex_t re;
regmatch_t pm[16];
int compiled;
} Desc;

Now the 'sizeof(regex_t)' from Tre is 8 and the posix is a lot more ... So when I call the 'regcomp' function like this:

switch(op) {
case COMPILE:
... snip ...
status = regcomp(&d->re, buf+8, flags);
d->compiled = 1;
... snip ...


The 'regmatch_t' is exactly overflowed by exactly
( sizeof (posix regex_t) - (2 * sizeof (tre regex_t)) ) 
bytes ...

This is the reason why I get a segfault (from my last post) when I try to call 'regexec'...

I'm now rewriting a simpler interface to libtre that will not have names that can collide with posix...

Sticky