Re: [EPIC]regexec on RH9 causes critical protection error

2003-07-16 Thread Jeremy Nelson
>assign re $regcomp(test)
>eval echo $regexec(re test)
>
>If you know how to use a debugger, it would be helpful if you 
>can get a stack trace, and cut and paste it here.
>
>Program received signal SIGSEGV, Segmentation fault.
>0x420bcf9c in re_search_internal () from /lib/tls/libc.so.6
>(gdb) bt
>#0  0x420bcf9c in re_search_internal () from /lib/tls/libc.so.6
>#1  0x420bc877 in regexec () from /lib/tls/libc.so.6
>#2  0x08067dc3 in function_regexec (input=0x80d952b "test") at functions.c:412
9

To follow up on this, the problem was that passing a string to $regex()
that was not returned from $regcomp() causes epic to crash.  It was suggested
that epic could do some basic sanity checking, and I have effected that
change.  The return value from $regexec() should be of a known length (it is
system dependant, but it can be calculated), and $regexec() will refuse any
regex that is not exactly the right length.  That should avoid the most 
likely errors.

Thanks for the report!
Jeremy
___
List mailing list
[EMAIL PROTECTED]
http://epicsol.org/mailman/listinfo/list


Re: [EPIC]regexec on RH9 causes critical protection error

2003-06-20 Thread Kev
> There is no way for epic to check whether the first argument to $regexec()
> is reasonable or not -- it has to trust the user to do the right thing.

If you're willing to add a bit of a wrapper, you can--add a magic number
to the beginning of the output from $regcomp() and check for it in
$regexec().  Of course, that won't help with bugs in regexec(), as this
seems to be, but...
-- 
Kevin L. Mitchell <[EMAIL PROTECTED]>

___
List mailing list
[EMAIL PROTECTED]
http://epicsol.org/mailman/listinfo/list


Re: [EPIC]regexec on RH9 causes critical protection error

2003-06-19 Thread Steve Hill
On Thu, Jun 19, 2003 at 11:07:10AM -0500, Jeremy Nelson wrote:
> >In the end the problem I had was caused by the RedHat regex engine
> >barfing on [[:<:]], even though it was documented in the manpage
> >(FreeBSDs was fine).

> Interesting -- can you give me the exact original RE?  We can others 
> who are using redhat (or other linux distros) to see if we can track
> this problem down.

I'm driving the regex with this:

alias re_match {
  @ :expr = [$0]
  @ :str  = [$1-]

  ^assign re_match_re $regcomp($expr)
  @ :rc = [$regexec($re_match_re $str)]
  eval $regfree($re_match_re)
  ^assign -re_match_re

  return $rc
}

Then I call:
re_match(\[\[:<:\]\]$xx\[\[:>:\]\] $tempStr)
where $xx obviously expands to something helpful. This will cause
a panic on RH but works fine on BSD. Apparently it also dies on
a recent Debian.

I have worked around it with the following abomination:
re_match(\(^|\[^\[:alnum:\]\]\)$xx\(\[^\[:alnum:\]\]|\$\) $tempStr)
Which works great on either.

I'd be very interested in an example of using $regerror() to trap
where $regcomp() fails. The following never seems to get triggered:

if ([$regerror($re)] != []) {
  # Do something
}

Steve

___
List mailing list
[EMAIL PROTECTED]
http://epicsol.org/mailman/listinfo/list


Re: [EPIC]regexec on RH9 causes critical protection error

2003-06-19 Thread Jeremy Nelson
>On Wed, Jun 18, 2003 at 05:51:44PM -0500, Jeremy Nelson wrote:
>> What you meant to do was:
>> 
>>  eval echo $regexec($re test)
>> ^ Note $ here.
>
>Ahem. My bad for submitting a bad testcase.
>
>In my actual code I had the missing $ but I managed to miss it when
>I tried to distill for testing/submission. Of course, I got
>exactly the same behaviour.
>
>In the end the problem I had was caused by the RedHat regex engine
>barfing on [[:<:]], even though it was documented in the manpage
>(FreeBSDs was fine).

Interesting -- can you give me the exact original RE?  We can others 
who are using redhat (or other linux distros) to see if we can track
this problem down.

Jeremy
___
List mailing list
[EMAIL PROTECTED]
http://epicsol.org/mailman/listinfo/list


Re: [EPIC]regexec on RH9 causes critical protection error

2003-06-19 Thread Steve Hill
On Wed, Jun 18, 2003 at 05:51:44PM -0500, Jeremy Nelson wrote:
> What you meant to do was:
> 
>  eval echo $regexec($re test)
> ^ Note $ here.

Ahem. My bad for submitting a bad testcase.

In my actual code I had the missing $ but I managed to miss it when
I tried to distill for testing/submission. Of course, I got
exactly the same behaviour.

In the end the problem I had was caused by the RedHat regex engine
barfing on [[:<:]], even though it was documented in the manpage
(FreeBSDs was fine).

I still couldnt get $regerror($failed_re) to return anything helpful
though :-/

I think I'll go hide my face now,
Steve
___
List mailing list
[EMAIL PROTECTED]
http://epicsol.org/mailman/listinfo/list


Re: [EPIC]regexec on RH9 causes critical protection error

2003-06-18 Thread Jeremy Nelson
>For the purposes of testing, my .ircrc was:
>
>assign re $regcomp(test)
>eval echo $regexec(re test)

Crashing here is actually the defined (but apparantly undocumented) behavior:
because the string 're' is not a value previously returned by $regcomp, 
passing it to $regexec() results in undefined behavior on every system.  
In your case, it crashes.  What you meant to do was:

 eval echo $regexec($re test)
^ Note $ here.

There is no way for epic to check whether the first argument to $regexec()
is reasonable or not -- it has to trust the user to do the right thing.

Jeremy
___
List mailing list
[EMAIL PROTECTED]
http://epicsol.org/mailman/listinfo/list


[EPIC]regexec on RH9 causes critical protection error

2003-06-18 Thread Steve Hill
Question one:  Please describe your computer system

Hardware type?
IBM Thinkpad T20 but seen on others

Operating System? (try uname -a for most, or uname -X for SCO)
RedHat Linux 9, 2.4.20-18.9

Your compiler (include version, if known)
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

What scripts/script packs you run (phoenix, uus, superpack, etc)
scrimpts

Anything else you think might be helpful.
glibc-2.3.2-27.9

Question two:  Where does your problem occur?
[ ]  Configure time (dies while running configure)
[ ]  Compiler time (dies when you type 'make')
[X]  Run time (You got a "CRITICAL PROTECTION ERROR")
[ ]  Run time (You got a "PANIC" message)
[ ]  Run time (non-fatal logic bug)

If it is at run time, please try to describe as best you can what
you were doing when the client malfunctioned.

For the purposes of testing, my .ircrc was:

assign re $regcomp(test)
eval echo $regexec(re test)

If you know how to use a debugger, it would be helpful if you 
can get a stack trace, and cut and paste it here.

Program received signal SIGSEGV, Segmentation fault.
0x420bcf9c in re_search_internal () from /lib/tls/libc.so.6
(gdb) bt
#0  0x420bcf9c in re_search_internal () from /lib/tls/libc.so.6
#1  0x420bc877 in regexec () from /lib/tls/libc.so.6
#2  0x08067dc3 in function_regexec (input=0x80d952b "test") at functions.c:4129
#3  0x08062595 in call_function (name=0xbfff7832 "REGEXEC", args=0x80b39e8 "",
args_flag=0xbfff78c4) at functions.c:684
#4  0x080540df in alias_special_char (buffer=0xbfff7878,
ptr=0xbfff7832 "REGEXEC", args=0x80b39e8 "", quote_em=0x0,
args_flag=0xbfff78c4) at expr.c:1785
#5  0x08053915 in expand_alias (string=0xbfff7894 "echo $regexec(re test)",
args=0x80b39e8 "", args_flag=0xbfff78c4, more_text=0xbfff78c8)
at expr.c:1341
#6  0x0805a69b in parse_line (name=0x0,
org_line=0xbfff7981 "echo $regexec(re test)", args=0x80b39e8 "",
hist_flag=0, append_flag=0) at commands.c:3274
#7  0x0805747a in evalcmd (command=0x809cc57 "EVAL",
args=0xbfff7981 "echo $regexec(re test)", subargs=0x0) at commands.c:1135
#8  0x0805ad96 in parse_command (
line=0xbfff797c "eval echo $regexec(re test)", hist_flag=0, sub_args=0x0)
at commands.c:3571
#9  0x0805a852 in parse_line (name=0x0,
org_line=0x80d9478 "eval echo $regexec(re test)", args=0x0, hist_flag=0,
append_flag=0) at commands.c:3309
#10 0x08058608 in load (command=0x80a6bff "LOAD", args=0x80b39e8 "",
subargs=0x80b39e8 "") at commands.c:1888
#11 0x080803d2 in got_initial_version_28 (ArgList=0xbfffcac8) at notice.c:392
#12 0x0808158d in numbered_command (from=0xbfffcb21 "efnet.xs4all.nl", comm=4,
ArgList=0xbfffcac4) at numbers.c:197
#13 0x080844a9 in parse_server (orig_line=0xbfffcb20 ":efnet.xs4all.nl")
at parse.c:1205
#14 0x08089e2a in do_server (rd=0xbfffeb48) at server.c:795
#15 0x080754cd in io (what=0x80a4454 "main") at ./irc.c:884
#16 0x08075aaa in main (argc=1, argv=0xbfffec34) at ./irc.c:1275
#17 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6

Please include any other information that you think we should know about.

Tested with:
ircII EPIC4-1.1.1 (Date of release: 2001)
ircII EPIC4-1.1.12 (Commit id: 524) (Date of release: 20030613)
___
List mailing list
[EMAIL PROTECTED]
http://epicsol.org/mailman/listinfo/list