Details
-
Task
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
Description
See notes below explaining what this task is about and how it is to be used.
Note: items in "Report to re-check" column can be crossed as closed. It is normal and does not mean that nothing needs to be done – they are closed because they are alleged duplicates, which is the whole point.
Original report | Report to re-check | Comments |
---|---|---|
MDEV-22768 | mdev22768a.test![]() |
my_message instead of my_error, 10.5 with --mysqld=--innodb (maybe not needed) |
MDEV-19680 | mdev19680-1.test![]() |
Unclear whether it's the same problem or not, will see when MDEV-19680 is closed |
MDEV-22883 | mdev22883-1.test![]() |
Unclear whether it's the same problem or not |
MDEV-24644 | mdev24644.test![]() |
Run with --nocheck-testcases --repeat=20 --force-restart |
MDEV-21406 | mdev21406.test![]() |
Causes assertion failure on 10.2 |
MDEV-23298 | mdev23298.test![]() |
|
|
mdev20410-1.test![]() |
On 10.2-10.3 |
MDEV-16694 | |
|
MDEV-21799 | mdev21799-1.test![]() |
The MDEV has become very messy, don't want to add anything to it anymore |
MDEV-27675 | mdev27675.test![]() |
Another ugly test case |
MDEV-24935 | mdev24935.test![]() |
Different assertion, same idea |
MDEV-16686 | mdev16686.test![]() |
Options in the test case |
|
mdev32683-mutex.test![]() |
Options in the test case |
MDEV-31178 | mdev31178-left-join.test![]() |
|
MDEV-26822 | |
Options in the test case |
MDEV-26509 | |
|
MDEV-32684 | |
Done
Original report | Report to re-check | Comments | Done |
---|---|---|---|
|
|
Check the test case without MIN/MAX | ![]() |
|
|
Check attached test case mdev17738-extra.test![]() |
![]() |
|
|
Check one if another gets fixed; check the attached test case mdev16905x.test![]() |
![]() |
|
|
Check the attached test case mdev16905x.test![]() |
|
|
|
Check attached test cases mdev18083-1.test.gz![]() ![]() ![]() ![]() ![]() Run each with options listed below and with and without --nocheck-testcases --nowarnings and with big --repeat=N |
|
|
When it reaches 10.4: warn3.test![]() |
||
|
|
Non-deterministic test case in |
|
|
mdev18485long.test![]() |
Run with --mem --default-server-options --mysqld=--log_output=FILE --mysqld=--loose-max-statement-time=3 --mysqld=--lock-wait-timeout=2 --mysqld=--loose-innodb-lock-wait-timeout=1 --mysqld=--loose-debug_assert_on_not_freed_memory=0 | |
|
|
There are alternative test cases in the comment(s), check them as well | |
|
|
mdev23182-virtual-method.test![]() |
|
|
|
MTR test case in comments and RQG test in the description | |
|
|
Check attached test cases mdev16788-1.test![]() ![]() |
|
|
|
Different test case, slightly different stack trace on Windows non-debug | |
|
mdev24665-1.test![]() |
Must be the same problem, but since it never gets fixed in full, better check | |
|
mdev24665-2.test![]() |
Must be the same problem, but since it never gets fixed in full, better check | |
|
mdev24583-1.test![]() |
Fails with THD::is_error on 10.4 | |
|
mdev24583-2.test![]() |
Details inside test files | |
|
mdev24583-3.test![]() |
Details inside test files | |
|
mdev24583-4.test![]() |
Details inside test files | |
|
mdev24958.test![]() |
On rel-ASAN build | |
|
mdev24786.test![]() |
Not necessarily the same bug, it's just a theory from a comment to |
|
|
MDEV-22733 | Test case in the description - doesn't hang for me, but possibly something else is wrong, leaving it be | |
|
mdev16128a.test![]() |
With --default-server-options | |
|
|
Options for MDEV-18083 |
-mem --default-server-options --mysqld=--log_output=FILE --mysqld=--max-statement-time=3 --mysqld=--lock-wait-timeout=2 --mysqld=--loose-innodb-lock-wait-timeout=1 --mysqld=--loose-debug_assert_on_not_freed_memory=0 --mysqld=--default-storage-engine=MyISAM --testcase-timeout=1
|
Notes:
It is going to be an on-going task until we find a better solution.
Quite often we get or create bug reports which are in all likelihood duplicates of some existing ones, but we can't be 100% sure until the original ones are fixed (even if the alleged duplicate has a test case). Keeping duplicates open is not really a solution, because original ones can stay open for months and years, and duplicates only add up the noise; and even when originals are fixed, unfortunately nobody goes through the alleged duplicates to re-verify and close them, so they stay orphans or get closed without any confirmation.
Another variation of the same problem is even when we have everything within the same bug report, the original test case can be huge and/or inconvenient for debugging, so we naturally try to simplify it. Often enough, we end up oversimplifying test cases, so when the small one gets fixed, the original one still fails. Again, unfortunately despite comments and requests to double-check before closing, it doesn't usually happen.
So, for now, I'm going to add here cases of both kinds which go through my hands. Every occurrence will be represented by a JIRA item which needs re-verification after some JIRA item gets closed. They can be either different items, or the same ones.
The task will be revised "on timer", triggered by moving due date, and notes will be added accordingly.
Everyone is welcome to add their own notes of the same kind, but please follow the pattern and do it only if the report which needs re-verification has a decently reproducible test case. This activity doesn't cover bugs which were not reproducible to begin with, and we are just guessing based on a stack trace or other effects that they might be duplicates of something.
Attachments
Issue Links
- is caused by
-
MDEV-11779 Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed in Diagnostics_area::set_ok_status upon UPDATE on partitioned table
-
- Closed
-