Re: [PATCH] mswin32-vc6 segmentation fault due ruby_in_eval wrong definition

=20

> -----Original Message-----
> From: Luis Lavena [mailto:[e-mail]]=20
> Sent: Wednesday, November 14, 2007 11:42 PM
> To: [e-mail]
> Subject: [PATCH] mswin32-vc6 segmentation fault due=20
> ruby_in_eval wrong definition
>=20
> Summary:
>=20
> Working in collaboration with Aman Gupta, we were trying to=20
> make ParseTree on Windows a fully working gem+extension.=20
> During the process of testing the changes, we found a=20
> segmentation fault raised by the C extension in ruby_in_eval=20
> increment:
>=20
> ruby_in_eval++;
> ... some code ...
> ruby_in_eval--;
>=20
> The synthetic code was reduced to this:
>=20
> #include "ruby.h"
> #include "env.h"
>=20
> void Init_test_in_eval()
> {
>=20
>   printf("&ruby_safe_level: %d\r\n", &ruby_safe_level);
>   printf("ruby_safe_level =3D %d\r\n", ruby_safe_level);
>=20
>   printf("&ruby_in_eval: %d\r\n", &ruby_in_eval);
>   printf("ruby_in_eval =3D %d\r\n", ruby_in_eval);
>=20
>   ruby_in_eval++;
>   ruby_in_eval--;
> }
>=20
> Trying to find why this was happening, found that env.h defined:
>=20
> extern int ruby_in_eval;
>=20
> in contrast with ruby_safe_level (ruby.h):
>=20
> RUBY_EXTERN int ruby_safe_level;
>=20
> I took ruby_safe_level for comparison only and isn't used=20
> directly by ParseTree code.
>=20
> This problem block us continue checking the ParseTree windows=20
> compatibility. ruby_in_eval was referenced but pointed to=20
> garbage memory...
>=20
> Solution:
>=20
> Attached is a patch for ruby_1_8 branch that correct this.=20
> Done a build test of the checkout with the modification in=20
> case this was used internally by ruby. Everything work=20
> without problems, now the test_in_eval extension and=20
> ParseTree compiles and run without crashes.
>=20
> Since 1.9 moved away from ruby_in_eval to rb_parse_in_eval()=20
> there is no need to back port the change to trunk.
>=20
> We are looking forward this patch gets committed.

Shouldn't they all be RUBY_EXTERN in config.h then?

Regards,

Dan


This communication is the property of Qwest and may contain confidential =
or
privileged information. Unauthorized use of this communication is =
strictly=20
prohibited and may be unlawful.  If you have received this communication =

in error, please immediately notify the sender by reply e-mail and =
destroy=20
all copies of the communication and any attachments.