Branko Čibej writes:
> Should be fixed in r1605739.
Yes, the tests now pass on my box.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
On 26.06.2014 13:15, Philip Martin wrote:
> Branko Čibej writes:
>
>> On 26.06.2014 13:04, Philip Martin wrote:
>>
>> Yup, I've been looking at exactly this spot and I suspect that I need to
>> make a copy of the hash table into the correct pool.
>>> (gdb) p ht
>>> $1 = (apr_hash_t *) 0x7fffd8060c
Branko Čibej writes:
> On 26.06.2014 13:04, Philip Martin wrote:
>
> Yup, I've been looking at exactly this spot and I suspect that I need to
> make a copy of the hash table into the correct pool.
>>
>> (gdb) p ht
>> $1 = (apr_hash_t *) 0x7fffd8060c60
>> (gdb) p ht[0]
>> $2 = {pool = 0x7fffd80064
On 26.06.2014 13:04, Philip Martin wrote:
> Branko Čibej writes:
>
>> Results from valgrind or a debugger are pretty much useless because
>> there appear to be cases where the JVM /expects/ segfaults to happen,
>> and handles them itself ... but valgrind doesn't know enough to ignore
>> them. Sinc
Branko Čibej writes:
> Results from valgrind or a debugger are pretty much useless because
> there appear to be cases where the JVM /expects/ segfaults to happen,
> and handles them itself ... but valgrind doesn't know enough to ignore
> them. Since they happen in different threads, the timing is
On 26.06.2014 12:22, Philip Martin wrote:
> Philip Martin writes:
>
>>> Can you please send the JVM stack trace file, too? Thanks.
>> I don't think it is much use as the exact crash varies from run to run.
>> It happens after different numbers of dots in the test output and the
>> stack trace vari
Branko Čibej writes:
> On 25.06.2014 14:43, Philip Martin wrote:
>> Philip Martin writes:
>>
>>> I'm getting a SEGV in the JVM and it varies from run to run, two
>>> examples at the end. I tried r1603298 and r1603297 and those also SEGV.
>> Looks like I made a mistake when building the older ve
On 25.06.2014 14:45, Philip Martin wrote:
> Philip Martin writes:
>
>> Philip Martin writes:
>>
>>> I'm getting a SEGV in the JVM and it varies from run to run, two
>>> examples at the end. I tried r1603298 and r1603297 and those also SEGV.
>> Looks like I made a mistake when building the older
On 25.06.2014 14:43, Philip Martin wrote:
> Philip Martin writes:
>
>> I'm getting a SEGV in the JVM and it varies from run to run, two
>> examples at the end. I tried r1603298 and r1603297 and those also SEGV.
> Looks like I made a mistake when building the older versions. I am now
> seeing the
Philip Martin writes:
> Philip Martin writes:
>
>> I'm getting a SEGV in the JVM and it varies from run to run, two
>> examples at the end. I tried r1603298 and r1603297 and those also SEGV.
>
> Looks like I made a mistake when building the older versions. I am now
> seeing the SEGV with r1603
Philip Martin writes:
> I'm getting a SEGV in the JVM and it varies from run to run, two
> examples at the end. I tried r1603298 and r1603297 and those also SEGV.
Looks like I made a mistake when building the older versions. I am now
seeing the SEGV with r1603306 but not with r1603305 or earli
Branko Čibej writes:
> On 24.06.2014 21:48, Bert Huijben wrote:
>> Hi,
>>
>> For some time the JavaHL tests on the svn-x64-ubuntu-gcc have been
>> segfaulting.
>>
>> Looking at
>> http://ci.apache.org/builders/svn-x64-ubuntu-gcc?numbuilds=200
>>
>> It appears this bot started failing after e
On 24.06.2014 21:48, Bert Huijben wrote:
> Hi,
>
> For some time the JavaHL tests on the svn-x64-ubuntu-gcc have been
> segfaulting.
>
> Looking at
> http://ci.apache.org/builders/svn-x64-ubuntu-gcc?numbuilds=200
>
> It appears this bot started failing after either
> r1603298 or r1603299
>
>
Hi,
For some time the JavaHL tests on the svn-x64-ubuntu-gcc have been
segfaulting.
Looking at
http://ci.apache.org/builders/svn-x64-ubuntu-gcc?numbuilds=200
It appears this bot started failing after either
r1603298 or r1603299
Other, similar bots don't produce the same segfault.
Can
14 matches
Mail list logo
