I had a few cases in regards to SER (v.0.9.6) process crashing and leaving core dumps. I've been debugging an issue and almost positive is in relation to the code that parses URI's. During a few test cases, I have been registering a user as "username@" in the username field. I believe something and somewhere is stomping on the heap and causing a memory exception error then crashes the process. I've included a core dump back trace while using GDB debugger.

In response to this issue I modified a bit of code to patch the problem. I am not submitting a fix to this issue just testing a temporary patch fix on my end for testing. Excuse my programming ignorance I am not a professional just submitting my findings to possibly fix this issue for my testing purposes.

Is it possible to send my core dumps to a developer to analyze this problem further? Please advise.

My current set-up is:

SER is configured using the auth radius module with FreeRADIUS and LDAP to authenticate a user.

SER 0.9.6 Radiusclient-NG 0.5.2 FreeRADIUS 1.1.0 iPlanet Directory Server 5.2 Red Hat Enterprise 3 WS

This is the Malformed URI that seems to crash SER. Notice the double "@@" in the registration URI:

parse_uri: bad host in uri (error at char @ in state 4) parsed: sip:mk%40@(10) /sip:mk%40@@x.x.x.x:3826 (30)

Possible place in (src/parser/parse_uri.c:476) where a bug resides:

case URI_HOST: switch(*p){ case '[': state=URI_HOST6_P; break; case ':': case ';': case '?': /* null host name ->invalid */ case '&': case '@': /*chars not allowed in hosts names */ - //goto error_bad_host; + p++; /* Hack Fix */ default: state=URI_HOST_P;

Back trace from 1 of 11 core dumps:

#0 0x0805934a in new_hash2 (call_id={s = 0xb7a1d9e1 <Address 0xb7a1d9e1 out of bounds>, len = -1214129699}, cseq_nr= {s = 0x522d6472 <Address 0x522d6472 out of bounds>, len = 1702131055}) at hash_func.c:119 119 v=(*p<<24)+(p[1]<<16)+(p[2]<<8)+p[3];