--- Begin Message ---
I'd be very surprised if it was a bug with Insure....it has found so many
bugs in our code, it is worth paying through the nose for (10k plus 2k a
year maint).
It does HEAVY type checking, and every single byte of memory is checked at
every access.
For instance on regexec, my HPUX 9.04 man page says:
int regexec(
const regex_t *preg,
const char *string,
size_t nmatch,
regmatch_t pmatch[],
int eflags
);
The regmatch_t structure contains at least the following members:
regoff_t rm_so Byte offset from start of string to
start of substring.
regoff_t rm_eo Byte offset from start of string to the
first character after the end of the
substring.
It's calling for a memory pointer the sizeof rematch_t.
If regexec where to read or write those structure elements, it stomp all
over address 0x00000.
On systems like the Amiga, it would crash it to a halt when accessing the
pointer 0x0000.
Perhaps it should be:
Regmatch_t rm;
Memset(&rm, 0, sizeof(Regmatch));
Regexec(,,,,&rm,);
That gives it logical memory to read and write to....???
Can you give me the "current source" and I will do a more in depth checking
on both HPUX9.0 and AIX4.2....
If I get the same errors on both platforms then we'll know there's a
problem.
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
-----Original Message-----
From: Ben Laurie [SMTP:[EMAIL PROTECTED]
Sent: Tuesday, May 26, 1998 2:53 PM
To: Dietz, Phil E.
Cc: [EMAIL PROTECTED]
Subject: Re: general/2245: Insure memory checker found errors
Dietz, Phil E. wrote:
>
> The following reply was made to PR general/2245; it has been noted
by GNATS.
>
> From: "Dietz, Phil E." <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: RE: general/2245: Insure memory checker found errors
> Date: Tue, 26 May 1998 12:27:51 -0500
>
> Here are a few of the errors from my preliminary test.
> We'll call this test 1.0 05/26/98.
>
> I'll post more as I can test more features.
>
> [http_main.c:985] **WRITE_DANGLING**
> >> ap_scoreboard_image->servers[my_child_num].timeout_len
= x;
>
> Writing to a dangling pointer: ap_scoreboard_image
>
> Pointer : 0xc271c000
> In block: 0xc271c000 thru 0xc271d403 (5124 bytes)
> block allocated at:
> shmat() (interface)
> setup_shared_mem() http_main.c, 1622
> reinit_scoreboard() http_main.c, 1735
> standalone_main() http_main.c, 3775
> main() http_main.c, 4039
>
> stack trace where memory was freed:
> shmctl() (interface)
> setup_shared_mem() http_main.c, 1646
> reinit_scoreboard() http_main.c, 1735
> standalone_main() http_main.c, 3775
> main() http_main.c, 4039
>
> Stack trace where the error occurred:
> ap_set_callback_and_alarm() http_main.c, 985
> ap_kill_timeout() http_main.c, 1069
> child_main() http_main.c, 3202
> make_child() http_main.c, 3555
> startup_children() http_main.c, 3582
> standalone_main() http_main.c, 3802
> main() http_main.c, 4039
It's difficult to be sure because the line numbers don't correspond
to
the current source, but this appears to be a bug in Insure. The
memory
was not freed in setup_shared_mem(), what actually happened is the
descriptor for it was deleted.
> [mod_setenvif.c:361] **PARM_NULL**
> >> if (!regexec(b->preg, val, 0, NULL, 0)) {
>
> Array parameter is null: pmatch
>
> Stack trace where the error occurred:
> regexec()
> match_headers() mod_setenvif.c, 361
> run_method() http_config.c, 352
> ap_run_post_read_request() http_config.c, 394
> ap_read_request() http_protocol.c, 800
> child_main() http_main.c, 3427
> make_child() http_main.c, 3555
> startup_children() http_main.c, 3582
> standalone_main() http_main.c, 3802
> main() http_main.c, 4039
This looks like another bug - the parameter is allowed to be NULL.
> [mod_log_config.c:387] **WRITE_OVERFLOW**
> >> strftime(tstr, MAX_STRING_LEN, "[%d/%b/%Y:%H:%M:%S ",
t);
>
> Writing overflows memory: <argument 1>
>
> bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
> | 592 | 7600 | 592 |
> wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
>
> Writing (w) : 0x7b033b78 thru 0x7b035b77 (8192 bytes)
> To block (b) : 0x7b033928 thru 0x7b035927 (8192 bytes)
> l, declared at http_protocol.c, 629
Another bug - the write cannot possibly take up 8192 bytes, though
it
may be more correct to limit it to the right amount.
In summary: it looks to me like your bug reports should go to the
authors of Insure, not us.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group
member
Freelance Consultant |Fax: +44 (181) 735
0689|http://www.apache.org
and Technical Director|Email: [EMAIL PROTECTED] |
A.L. Digital Ltd, |Apache-SSL author
http://www.apache-ssl.org/
London, England. |"Apache: TDG"
http://www.ora.com/catalog/apache
--- End Message ---
