Hi Otto,
On Fri, 2024-07-05 at 23:00 -0700, Otto Kekäläinen wrote:
> Thanks for the tips. Unfortunately running just the single test
> without any other load on the system still crashes it and system load
> was otherwise zero, so it is not due to slowness.
Single-core performance on SPARC is
Thanks for the tips. Unfortunately running just the single test
without any other load on the system still crashes it and system load
was otherwise zero, so it is not due to slowness.
I also tested explicit debug run and various ways to invoke gdb, but
--debug didn't yield any new info and all
./sql/ha_partition.cc:5657 is coping over a blob of memory.
Could it just be slow? Does running main.partition on its own
generate the same result?
Alternately one of the loop constructs around it got some incorrect
values. Examine local variables (info locals) around what was
executing on
I built the binary in debug mode and that yielded a stacktrace:
***
main.partition w38 [ retry-fail ]
Test ended at 2024-07-06 01:14:43
CURRENT_TEST: main.partition
mysqltest: At line 3010: query 'select id from t1 where data =
Hi!
On Tue, 2 Jul 2024 at 23:24, John Paul Adrian Glaubitz
wrote:
>
> Hello Otto,
>
> On Tue, 2024-07-02 at 21:10 -0700, Otto Kekäläinen wrote:
> > I recently uploaded MariaDB 11.4 to Debian, and it seems it regressed
> > on sparc64.
> >
> > Are there any sparc64 hackers interested in taking a
Hello Otto,
On Tue, 2024-07-02 at 21:10 -0700, Otto Kekäläinen wrote:
> I recently uploaded MariaDB 11.4 to Debian, and it seems it regressed
> on sparc64.
>
> Are there any sparc64 hackers interested in taking a look?
>
> The build itself passed and most of the post-build passes, but some
>
Hi!
I recently uploaded MariaDB 11.4 to Debian, and it seems it regressed
on sparc64.
Are there any sparc64 hackers interested in taking a look?
The build itself passed and most of the post-build passes, but some
tests cause the database to crash. Stack traces are visible in the
logs:
7 matches
Mail list logo