Bug#651529: rsyslog: FTBFS on hurd-i386

[Rainer Gerhards]

> > We have a bugzilla at http://bugzilla.adiscon.com and the mailing list
> > is at http://lists.adiscon.net/mailman/listinfo/rsyslog
> >
> > Which way you use doesn't really matter to me, I am fine with either way.
> > Just note that anything that is related to the packaging is not
> > touched by me. I follow the debian bug tracker and try to pull out
> > things that I can address. Michael does a great job to remind me if I
> > overlook things (what happens...).
> 
> Of course, I know packaging issues are not touched by upstream, so the
> configuration/startup scripts are Debian specific, right? 

Yes

> Then, I'll file a Debian
> bug for /etc/init.d/rsyslog. Another issue is about writing a Hurd-specific
> plugin file: plugins/imklog/gnu.c. However, this is not an urgent matter so
it
> can wait until later. Thanks!


Definitely interested in that if the "regular" one has problems.

> 
> > Just be warned that I will soon leave for xmas vacation and I have a
> > big bunch of things in front of me, so I will probably not be able to
> > change anything before I leave.
> 
> I wish you a Merry Christmas then :)
Same to you ;)

Rainer

Bug#651529: rsyslog: FTBFS on hurd-i386

[Svante Signell]

On Fri, 2011-12-16 at 14:32 +0100, Rainer Gerhards wrote:
> > Good that you took the time to change the code, I'm currently working on
> > completing the dynamic allocation solution. 
> 
> It's important to note that I used the chance to refactor the code a bit, so
> the logic is slightly different. When you read the code, note that I use a
> stack-based fixed size buffer as long as it is sufficient and go to dyn
> alloced memory only if necessary. I guess dyn alloc will never happen in
> practice (but I tested under valgrind control and it looks rather well).

OK!

> We have a bugzilla at http://bugzilla.adiscon.com and the mailing list is at
> http://lists.adiscon.net/mailman/listinfo/rsyslog 
> 
> Which way you use doesn't really matter to me, I am fine with either way.
> Just note that anything that is related to the packaging is not touched by
> me. I follow the debian bug tracker and try to pull out things that I can
> address. Michael does a great job to remind me if I overlook things (what
> happens...).  

Of course, I know packaging issues are not touched by upstream, so the
configuration/startup scripts are Debian specific, right? Then, I'll
file a Debian bug for /etc/init.d/rsyslog. Another issue is about
writing a Hurd-specific plugin file: plugins/imklog/gnu.c. However, this
is not an urgent matter so it can wait until later. Thanks!

> Just be warned that I will soon leave for xmas vacation and I
> have a big bunch of things in front of me, so I will probably not be able to
> change anything before I leave.

I wish you a Merry Christmas then :)




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#651529: rsyslog: FTBFS on hurd-i386

[Rainer Gerhards]

> Good that you took the time to change the code, I'm currently working on
> completing the dynamic allocation solution. 

It's important to note that I used the chance to refactor the code a bit, so
the logic is slightly different. When you read the code, note that I use a
stack-based fixed size buffer as long as it is sufficient and go to dyn
alloced memory only if necessary. I guess dyn alloc will never happen in
practice (but I tested under valgrind control and it looks rather well).

> I'll take a look at your changes,
> thank you. If Guillem is happy with your changes, let's settle with your
> solution.
> 
> I have some more issues now when the package is building on GNU/Hurd,
> one is the configuration file. Is it OK to submit another bug report to the
> Debian bug data base? Or do you want me to contact the development list (if
> it exists) or you directly?

We have a bugzilla at http://bugzilla.adiscon.com and the mailing list is at
http://lists.adiscon.net/mailman/listinfo/rsyslog 

Which way you use doesn't really matter to me, I am fine with either way.
Just note that anything that is related to the packaging is not touched by
me. I follow the debian bug tracker and try to pull out things that I can
address. Michael does a great job to remind me if I overlook things (what
happens...).  Just be warned that I will soon leave for xmas vacation and I
have a big bunch of things in front of me, so I will probably not be able to
change anything before I leave.

Rainer

Bug#651529: rsyslog: FTBFS on hurd-i386

[Svante Signell]

On Fri, 2011-12-16 at 12:18 +0100, Rainer Gerhards wrote:
> > While that could be the easy way out, it would definitely be wrong.
> > Such limits can be OS or filesystem specific, if at all. They do not even
> > represent reality on GNU/Linux! Try this:
> 
> I try to stay out of these politics, but I found it beneficial to remove the
> dependency on MAX_PATH. It actually solved two error conditions that
> otherwise could occur (not sure if the dlopen call will fail in these cases,
> though). At least the code got smaller.
> 
> I have enhanced v5-devel, patch is available here:
> 
> http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=01c7c9ffc6771f73df9ee0bc
> 18e30534d6c6974c
> 
> I would appreciate if you could have a look at it; the pointer arithmetic is
> obviously easy to get wrong.

Good that you took the time to change the code, I'm currently working on
completing the dynamic allocation solution. I'll take a look at your
changes, thank you. If Guillem is happy with your changes, let's settle
with your solution.

I have some more issues now when the package is building on GNU/Hurd,
one is the configuration file. Is it OK to submit another bug report to
the Debian bug data base? Or do you want me to contact the development
list (if it exists) or you directly? 




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#651529: rsyslog: FTBFS on hurd-i386

[Rainer Gerhards]

> While that could be the easy way out, it would definitely be wrong.
> Such limits can be OS or filesystem specific, if at all. They do not even
> represent reality on GNU/Linux! Try this:

I try to stay out of these politics, but I found it beneficial to remove the
dependency on MAX_PATH. It actually solved two error conditions that
otherwise could occur (not sure if the dlopen call will fail in these cases,
though). At least the code got smaller.

I have enhanced v5-devel, patch is available here:

http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=01c7c9ffc6771f73df9ee0bc
18e30534d6c6974c

I would appreciate if you could have a look at it; the pointer arithmetic is
obviously easy to get wrong.

Thanks,
Rainer



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#651529: rsyslog: FTBFS on hurd-i386

[Guillem Jover]

Hi!

On Tue, 2011-12-13 at 18:44:11 +0100, Michael Biebl wrote:
> but WTH does GNU/hurd not simply #define PATH_MAX and be done with it.

While that could be the easy way out, it would definitely be wrong.
Such limits can be OS or filesystem specific, if at all. They do not
even represent reality on GNU/Linux! Try this:

$ printf '#include \nPATH_MAX' | cpp -P
$ d=0123456789; for i in `seq 1 1000`; do mkdir $d; cd $d 2>/dev/null; done
$ pwd | wc -c

pwd(1) is even specified to be able to return paths longer than
PATH_MAX by POSIX:

  

Also once set, the MAX macros becomes part of the ABI, and cannot be
increased w/o recompiling any code using them.

As such, using dynamically allocated buffers while it might seem a bit
more work, it also seems superior in all other accounts, it will use
less memory, it should not suffer from accidental truncation, it will
accomodate any arbitrary path length w/o problem, etc.

In any case, I'd rather see the MAX macros removed from GNU/*.

> This would solve 90% of the build failures we have in Debian.

On 2007 Michael Banck did some analysis [0] and from that around 20%
could be said to be affected definitely by MAX macro issues. While now
pretty outdated, I've serious doubts the % has changed so much to get
close to the number you wrote above?

 [0] 

> This all looks like a major waste of time to me.

Well, writing correct software takes time, yes.

regards,
guillem



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#651529: rsyslog: FTBFS on hurd-i386

[Svante Signell]

On Tue, 2011-12-13 at 18:44 +0100, Michael Biebl wrote:
> Thanks for all the efforts, but WTH does GNU/Hurd not simply #define
> PATH_MAX and be done with it. This would solve 90% of the build failures
> we have in Debian.
> This all looks like a major waste of time to me.

It might look like that but it is not an option, according to the
hardcore GNU/Hurd people, end of that discussion, sorry :-( So as
porters we try to do do our best within the restrictions given ...




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#651529: rsyslog: FTBFS on hurd-i386

[Michael Biebl]

Thanks for all the efforts, but WTH does GNU/hurd not simply #define
PATH_MAX and be done with it. This would solve 90% of the build failures
we have in Debian.
This all looks like a major waste of time to me.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#651529: rsyslog: FTBFS on hurd-i386

[Guillem Jover]

Hi!

On Tue, 2011-12-13 at 09:50:21 +0100, Svante Signell wrote:
> On Tue, 2011-12-13 at 06:41 +0100, Guillem Jover wrote:
> > On Fri, 2011-12-09 at 16:40:41 +0100, Svante Signell wrote:
> > > Source: rsyslog
> > > Version: 5.8.6-1
> > > Severity: important
> > > Tags: patch
> > > User: debian-h...@lists.debian.org
> > > Usertags: hurd

> --- rsyslog-5.8.6/runtime/modules.c   2011-10-21 11:53:02.0 +0200
> +++ rsyslog-5.8.6.modified/runtime/modules.c  2011-12-13 09:25:16.0 
> +0100
> @@ -767,9 +767,9 @@
>   DEFiRet;
>   
>   size_t iPathLen, iModNameLen;
> - uchar szPath[PATH_MAX];
> + uchar *szPath = NULL;
>   uchar *pModNameCmp;
> - int bHasExtension;
> + int bHasExtension, pHasSlash;
>  void *pModHdlr, *pModInit;
>   modInfo_t *pModInfo;
>   uchar *pModDirCurr, *pModDirNext;
> @@ -805,12 +805,16 @@
>   do {
>   /* now build our load module name */
>   if(*pModName == '/' || *pModName == '.') {
> - *szPath = '\0'; /* we do not need to append the path - 
> its already in the module name */
> + *szPath = '\0'; /* we do not need to append the path - 
> its already in the module name */

Still not allocating, and now assigning which will segfault right away.
Allocation should happen as the first thing on the loop, before any
modification to szPath.

>   iPathLen = 0;
>   } else {
> - *szPath = '\0';
> -
>   iPathLen = strlen((char *)pModDirCurr);
> + if(pModDirCurr[iPathLen - 1] == '/')
> + pHasSlash = TRUE;
> + else {
> + iPathLen += iPathLen;

Why doubling the memory required? Just 1 would be enough I'd say.

> + pHasSlash = FALSE;
> + }
>   pModDirNext = (uchar *)strchr((char *)pModDirCurr, ':');
>   if(pModDirNext)
>   iPathLen = (size_t)(pModDirNext - pModDirCurr);
> @@ -821,45 +825,38 @@
>   continue;
>   }
>   break;
> - } else if(iPathLen > sizeof(szPath) - 1) {
> - errmsg.LogError(0, NO_ERRCODE, "could not load 
> module '%s', module path too long\n", pModName);
> + }
> + if(szPath != NULL)
> + free(szPath);
> + iPathLen = iPathLen + iModNameLen + 3;

This will make the subsequent handling of pHasSlash bogus.

> + if((szPath = malloc(iPathLen+1)) == NULL) {
> + errmsg.LogError(0, NO_ERRCODE, "could not 
> allocate memory '%s'\n", pModName);
>   ABORT_FINALIZE(RS_RET_MODULE_LOAD_ERR_PATHLEN);
>   }
>  
> - strncat((char *) szPath, (char *)pModDirCurr, iPathLen);
> - iPathLen = strlen((char*) szPath);
> + strcpy((char *) szPath, (char *)pModDirCurr);
>  
>   if(pModDirNext)
>   pModDirCurr = pModDirNext + 1;
>  
> - if((szPath[iPathLen - 1] != '/')) {
> - if((iPathLen <= sizeof(szPath) - 2)) {
> - szPath[iPathLen++] = '/';
> - szPath[iPathLen] = '\0';
> - } else {
> - errmsg.LogError(0, 
> RS_RET_MODULE_LOAD_ERR_PATHLEN, "could not load module '%s', path too 
> long\n", pModName);
> - 
> ABORT_FINALIZE(RS_RET_MODULE_LOAD_ERR_PATHLEN);
> - }
> + if(!pHasSlash) {
> + szPath[iPathLen - 2] = '/';
> + szPath[iPathLen - 1] = '\0';

iPathLen does not point anymore to the actual end of the written string,
but to the end of the allocated memory. In addition -2 would not be
right either, as if '/' is not found in - 1 (pHasSlash), then we have
to append it, which means just iPathLen. This is the code as can be
seen originally.

regards,
guillem



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#651529: rsyslog: FTBFS on hurd-i386

[Svante Signell]

On Tue, 2011-12-13 at 06:41 +0100, Guillem Jover wrote:
> Hi!
> 
> On Fri, 2011-12-09 at 16:40:41 +0100, Svante Signell wrote:
> > Source: rsyslog
> > Version: 5.8.6-1
> > Severity: important
> > Tags: patch
> > User: debian-h...@lists.debian.org
> > Usertags: hurd
...
> > diff -ur rsyslog-5.8.6/runtime/modules.c 
> > rsyslog-5.8.6.buggy/runtime/modules.c
> > --- rsyslog-5.8.6/runtime/modules.c 2011-10-21 11:53:02.0 +0200
> > +++ rsyslog-5.8.6.modified/runtime/modules.c2011-12-09 
> > 14:40:08.0 +0100
...
> > @@ -805,11 +805,8 @@
> > do {
> > /* now build our load module name */
> > if(*pModName == '/' || *pModName == '.') {
> > -   *szPath = '\0'; /* we do not need to append the path - 
> > its already in the module name */
> > iPathLen = 0;
> 
> On this case no memory is allocated which will cause a segfault,
> further on when writing to szPath.

Fixed!

> > } else {
> > -   *szPath = '\0';
> > -
> > iPathLen = strlen((char *)pModDirCurr);
> > pModDirNext = (uchar *)strchr((char *)pModDirCurr, ':');
> > if(pModDirNext)
> > @@ -821,45 +818,41 @@
> > continue;
> > }
> > break;
> > -   } else if(iPathLen > sizeof(szPath) - 1) {
> > -   errmsg.LogError(0, NO_ERRCODE, "could not load 
> > module '%s', module path too long\n", pModName);
> > +   }
> > +   if((szPath = malloc(iPathLen+1)) == NULL) {
> > +   errmsg.LogError(0, NO_ERRCODE, "could not 
> > allocate memory '%s'\n", pModName);
> > ABORT_FINALIZE(RS_RET_MODULE_LOAD_ERR_PATHLEN);
> > }
> >  
> > -   strncat((char *) szPath, (char *)pModDirCurr, iPathLen);
> > -   iPathLen = strlen((char*) szPath);
> > +   strcpy((char *) szPath, (char *)pModDirCurr);
> >  
> > if(pModDirNext)
> > pModDirCurr = pModDirNext + 1;
> >  
> > if((szPath[iPathLen - 1] != '/')) {
> > -   if((iPathLen <= sizeof(szPath) - 2)) {
> > -   szPath[iPathLen++] = '/';
> > -   szPath[iPathLen] = '\0';
> > -   } else {
> > -   errmsg.LogError(0, 
> > RS_RET_MODULE_LOAD_ERR_PATHLEN, "could not load module '%s', path too 
> > long\n", pModName);
> > -   
> > ABORT_FINALIZE(RS_RET_MODULE_LOAD_ERR_PATHLEN);
> > -   }
> > +   szPath[iPathLen++] = '/';
> > +   szPath[iPathLen] = '\0';
> 
> This will write past the last character. You need to allocate +1
> additional byte for it.

Fixed!

> > }
> > }
> >  
> > /* ... add actual name ... */
> > -   strncat((char *) szPath, (char *) pModName, sizeof(szPath) - 
> > iPathLen - 1);
> > +   iPathLen = iPathLen + iModNameLen + 3;
> > +   if((szPath = realloc(szPath, iPathLen+1)) == NULL) {
> > +   errmsg.LogError(0, NO_ERRCODE, "could not allocate memory 
> > '%s'\n", pModName);
> > +   ABORT_FINALIZE(RS_RET_MODULE_LOAD_ERR_PATHLEN);
> > + }
> 
> This will do useless work that could be avoided. Pre-compute the total
> path len and use a single malloc() instead.

This is a matter of how much you should change in the original code. I
thought about it but decided not to by then. Now the updated patch does.

> >  
> > /* now see if we have an extension and, if not, append ".so" */
> > -   if(!bHasExtension) {
> > +   if(bHasExtension) {
...
> > /* complete load path constructed, so ... GO! */
> > @@ -903,6 +896,7 @@
> > }
> >  
> >  finalize_it:
> > +   free(szPath);
> > pthread_mutex_unlock(&mutLoadUnload);
> > RETiRet;
> >  }
> 
> It seems (w/o looking at the full function) this will leak if the loop is
> repeated for whatever reason, and szPath will get malloc()ed over.

This was fixed by an update to the patch, sent to the bug number but not
to the debian-hurd ML.

> The function can probably be simplified quite a bit, by allocating
> once at the beginning of the loop and then using sprintf() to build
> the path.

See above!
--- rsyslog-5.8.6/runtime/modules.c	2011-10-21 11:53:02.0 +0200
+++ rsyslog-5.8.6.modified/runtime/modules.c	2011-12-13 09:25:16.0 +0100
@@ -767,9 +767,9 @@
 	DEFiRet;
 	
 	size_t iPathLen, iModNameLen;
-	uchar szPath[PATH_MAX];
+	uchar *szPath = NULL;
 	uchar *pModNameCmp;
-	int bHasExtension;
+	int bHasExtension, pHasSlash;
 void *pModHdlr, *pModInit;
 	modInfo_t *pModInfo;
 	uchar *pModDir

Bug#651529: rsyslog: FTBFS on hurd-i386

[Guillem Jover]

Hi!

On Fri, 2011-12-09 at 16:40:41 +0100, Svante Signell wrote:
> Source: rsyslog
> Version: 5.8.6-1
> Severity: important
> Tags: patch
> User: debian-h...@lists.debian.org
> Usertags: hurd

> rsyslog FTBFS on GNU/Hurd due to the usage of PATH_MAX in one function
> static rsRetVal Load(uchar *pModName) in file realtime/modules.c. The
> attached patch use dynamic allocation of strings instead of fixed length
> ones. The number of changes are maybe on the order to check with
> upstream if they are OK. A test program for the construct has been
> created and works. The built package has also been installed kvm box and
> been running there for a while and does also work.

> diff -ur rsyslog-5.8.6/runtime/modules.c rsyslog-5.8.6.buggy/runtime/modules.c
> --- rsyslog-5.8.6/runtime/modules.c   2011-10-21 11:53:02.0 +0200
> +++ rsyslog-5.8.6.modified/runtime/modules.c  2011-12-09 14:40:08.0 
> +0100
> @@ -767,7 +767,7 @@
>   DEFiRet;
>   
>   size_t iPathLen, iModNameLen;
> - uchar szPath[PATH_MAX];
> + uchar *szPath = NULL;
>   uchar *pModNameCmp;
>   int bHasExtension;
>  void *pModHdlr, *pModInit;
> @@ -805,11 +805,8 @@
>   do {
>   /* now build our load module name */
>   if(*pModName == '/' || *pModName == '.') {
> - *szPath = '\0'; /* we do not need to append the path - 
> its already in the module name */
>   iPathLen = 0;

On this case no memory is allocated which will cause a segfault,
further on when writing to szPath.

>   } else {
> - *szPath = '\0';
> -
>   iPathLen = strlen((char *)pModDirCurr);
>   pModDirNext = (uchar *)strchr((char *)pModDirCurr, ':');
>   if(pModDirNext)
> @@ -821,45 +818,41 @@
>   continue;
>   }
>   break;
> - } else if(iPathLen > sizeof(szPath) - 1) {
> - errmsg.LogError(0, NO_ERRCODE, "could not load 
> module '%s', module path too long\n", pModName);
> + }
> + if((szPath = malloc(iPathLen+1)) == NULL) {
> + errmsg.LogError(0, NO_ERRCODE, "could not 
> allocate memory '%s'\n", pModName);
>   ABORT_FINALIZE(RS_RET_MODULE_LOAD_ERR_PATHLEN);
>   }
>  
> - strncat((char *) szPath, (char *)pModDirCurr, iPathLen);
> - iPathLen = strlen((char*) szPath);
> + strcpy((char *) szPath, (char *)pModDirCurr);
>  
>   if(pModDirNext)
>   pModDirCurr = pModDirNext + 1;
>  
>   if((szPath[iPathLen - 1] != '/')) {
> - if((iPathLen <= sizeof(szPath) - 2)) {
> - szPath[iPathLen++] = '/';
> - szPath[iPathLen] = '\0';
> - } else {
> - errmsg.LogError(0, 
> RS_RET_MODULE_LOAD_ERR_PATHLEN, "could not load module '%s', path too 
> long\n", pModName);
> - 
> ABORT_FINALIZE(RS_RET_MODULE_LOAD_ERR_PATHLEN);
> - }
> + szPath[iPathLen++] = '/';
> + szPath[iPathLen] = '\0';

This will write past the last character. You need to allocate +1
additional byte for it.

>   }
>   }
>  
>   /* ... add actual name ... */
> - strncat((char *) szPath, (char *) pModName, sizeof(szPath) - 
> iPathLen - 1);
> + iPathLen = iPathLen + iModNameLen + 3;
> + if((szPath = realloc(szPath, iPathLen+1)) == NULL) {
> + errmsg.LogError(0, NO_ERRCODE, "could not allocate memory 
> '%s'\n", pModName);
> + ABORT_FINALIZE(RS_RET_MODULE_LOAD_ERR_PATHLEN);
> +   }

This will do useless work that could be avoided. Pre-compute the total
path len and use a single malloc() instead.

>  
>   /* now see if we have an extension and, if not, append ".so" */
> - if(!bHasExtension) {
> + if(bHasExtension) {
> +   strncat((char *) szPath, (char *) pModName, iModNameLen+3);
> + } else {
>   /* we do not have an extension and so need to add ".so"
>* TODO: I guess this is highly importable, so we 
> should change the
>* algo over time... -- rgerhards, 2008-03-05
>*/
>   /* ... so now add the extension */
> - strncat((char *) szPath, ".so", sizeof(szPath) - 
> strlen((char*) szPath) - 1);
> - iPathLen += 3;
> - }
> -
> - if(iPathLen +

Bug#651529: rsyslog: FTBFS on hurd-i386

[Svante Signell]

Source: rsyslog
Version: 5.8.6-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

rsyslog FTBFS on GNU/Hurd due to the usage of PATH_MAX in one function
static rsRetVal Load(uchar *pModName) in file realtime/modules.c. The
attached patch use dynamic allocation of strings instead of fixed length
ones. The number of changes are maybe on the order to check with
upstream if they are OK. A test program for the construct has been
created and works. The built package has also been installed kvm box and
been running there for a while and does also work.

Thanks!
diff -ur rsyslog-5.8.6/runtime/modules.c rsyslog-5.8.6.buggy/runtime/modules.c
--- rsyslog-5.8.6/runtime/modules.c	2011-10-21 11:53:02.0 +0200
+++ rsyslog-5.8.6.modified/runtime/modules.c	2011-12-09 14:40:08.0 +0100
@@ -767,7 +767,7 @@
 	DEFiRet;
 	
 	size_t iPathLen, iModNameLen;
-	uchar szPath[PATH_MAX];
+	uchar *szPath = NULL;
 	uchar *pModNameCmp;
 	int bHasExtension;
 void *pModHdlr, *pModInit;
@@ -805,11 +805,8 @@
 	do {
 		/* now build our load module name */
 		if(*pModName == '/' || *pModName == '.') {
-			*szPath = '\0';	/* we do not need to append the path - its already in the module name */
 			iPathLen = 0;
 		} else {
-			*szPath = '\0';
-
 			iPathLen = strlen((char *)pModDirCurr);
 			pModDirNext = (uchar *)strchr((char *)pModDirCurr, ':');
 			if(pModDirNext)
@@ -821,45 +818,41 @@
 	continue;
 }
 break;
-			} else if(iPathLen > sizeof(szPath) - 1) {
-errmsg.LogError(0, NO_ERRCODE, "could not load module '%s', module path too long\n", pModName);
+			}
+			if((szPath = malloc(iPathLen+1)) == NULL) {
+errmsg.LogError(0, NO_ERRCODE, "could not allocate memory '%s'\n", pModName);
 ABORT_FINALIZE(RS_RET_MODULE_LOAD_ERR_PATHLEN);
 			}
 
-			strncat((char *) szPath, (char *)pModDirCurr, iPathLen);
-			iPathLen = strlen((char*) szPath);
+			strcpy((char *) szPath, (char *)pModDirCurr);
 
 			if(pModDirNext)
 pModDirCurr = pModDirNext + 1;
 
 			if((szPath[iPathLen - 1] != '/')) {
-if((iPathLen <= sizeof(szPath) - 2)) {
-	szPath[iPathLen++] = '/';
-	szPath[iPathLen] = '\0';
-} else {
-	errmsg.LogError(0, RS_RET_MODULE_LOAD_ERR_PATHLEN, "could not load module '%s', path too long\n", pModName);
-	ABORT_FINALIZE(RS_RET_MODULE_LOAD_ERR_PATHLEN);
-}
+szPath[iPathLen++] = '/';
+szPath[iPathLen] = '\0';
 			}
 		}
 
 		/* ... add actual name ... */
-		strncat((char *) szPath, (char *) pModName, sizeof(szPath) - iPathLen - 1);
+		iPathLen = iPathLen + iModNameLen + 3;
+		if((szPath = realloc(szPath, iPathLen+1)) == NULL) {
+		errmsg.LogError(0, NO_ERRCODE, "could not allocate memory '%s'\n", pModName);
+		ABORT_FINALIZE(RS_RET_MODULE_LOAD_ERR_PATHLEN);
+		  }
 
 		/* now see if we have an extension and, if not, append ".so" */
-		if(!bHasExtension) {
+		if(bHasExtension) {
+		  strncat((char *) szPath, (char *) pModName, iModNameLen+3);
+		} else {
 			/* we do not have an extension and so need to add ".so"
 			 * TODO: I guess this is highly importable, so we should change the
 			 * algo over time... -- rgerhards, 2008-03-05
 			 */
 			/* ... so now add the extension */
-			strncat((char *) szPath, ".so", sizeof(szPath) - strlen((char*) szPath) - 1);
-			iPathLen += 3;
-		}
-
-		if(iPathLen + strlen((char*) pModName) >= sizeof(szPath)) {
-			errmsg.LogError(0, RS_RET_MODULE_LOAD_ERR_PATHLEN, "could not load module '%s', path too long\n", pModName);
-			ABORT_FINALIZE(RS_RET_MODULE_LOAD_ERR_PATHLEN);
+			strncat((char *) szPath, (char *) pModName, iModNameLen);
+			strncat((char *) szPath, ".so", 3);
 		}
 
 		/* complete load path constructed, so ... GO! */
@@ -903,6 +896,7 @@
 	}
 
 finalize_it:
+	free(szPath);
 	pthread_mutex_unlock(&mutLoadUnload);
 	RETiRet;
 }