On Sun, 14 Sep 2003, Stas Bekman wrote: > Randy Kobes wrote: > > On Sun, 14 Sep 2003, Randy Kobes wrote: > > > > > >>On Sun, 14 Sep 2003, Stas Bekman wrote: > >> > >> > >>>Randy Kobes wrote: > >>> > >>>>With the current cvs mod_perl 2 on Win32, I'm having a > >>>>problem running the filter tests from 'nmake test': > >>>>the following occurs in subtest 3 (I think) of > >>>>t/filter/both_str_con_add: > >>> > >>>could it be that it has something to do with geoff's recent patch: > >>>http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106346593832576&w=2 > >>>does the problem disappear if you revert it? > >> > >>No, the same problem arises with and without that patch > >>(actually, I held off reporting this, in case that patch > >>fixed it). > > Cool. > > > I've just tried this with perl-5.8.1, but the same problem > > arises (for this, I had to undefine MP_NEED_HASH_SEED_FIXUP > > in src/modules/perl/mod_perl.c, as otherwise the server > > won't start). > > What is the problem with it? It won't quite work without > this fixup on the latest 5.8.1.
Leaving in MP_NEED_HASH_SEED_FIXUP as defined won't allow the server to even start (with perl-5.8.1 on Win32). Just to see, I tried undefining it, and the server did start, and the tests started running, but then bombed out when it got to the filter tests. This is the same behaviour (and at the same place) as with perl-5.8.0 on Win32, where MP_NEED_HASH_SEED_FIXUP is undefined. As was mentioned on another message, the problem with MP_NEED_HASH_SEED_FIXUP seems to be in the safemalloc() call in src/modules/perl/mod_perl.c, in the modperl_hash_seed_init() function. Just as an experiment, I tried changing this to call malloc() instead - with this, the server did start, and the tests started running, but then crashed later, before the filter tests. I know using malloc() isn't the right thing to do, so I didn't look further. > > And again, the problem arises with 'nmake > > test', but using 'perl t/TEST t/filter' allows all filter > > tests to pass (including one that failed with perl-5.8.0 on > > Win32). > > You mean things fails when you run all tests and succeed > only if you run t/filter tests, is that right? If that's > the case, some previously run tests affect the latter > tests. t/SMOKE is written especially for the purpose to > figure out which minimal sequence of tests triggers the > problem. That's right - if one runs t/filter alone, all the filter tests pass; the problem arises in running all the tests. I'll look at t/SMOKE. > I suspect that the problem has surfaced after I have > changed the number of running servers from one to two to > allow the proxy work. What happens if you make the proxy > filter skip and run the tests with only one server > available? I bet they will all work. I'll try that .... > That recent change in the number of running servers has > revealed several other problems, which I'm trying to debug > now. Unfortunately they happen at random and therefore > hard to debug. Re-using the same HASH_SEED makes it easier > to reproduce, but not in all cases. > > > Anyway, here's a trace, this time with the Perl symbols: > > does it mean that you get a segfault? The Windows equivalent, yes ... The message that comes up is an access violation in mod_perl.so. -- best regards, randy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
