View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0012580 | mantisbt | bugtracker | public | 2010-12-05 09:42 | 2014-09-23 18:05 |
Reporter | syzop | Assigned To | dregad | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Product Version | 1.2.3 | ||||
Target Version | 1.2.12 | Fixed in Version | 1.2.12 | ||
Summary | 0012580: Issue x not found (for bug y) | ||||
Description | Any idea what this is? The issue is 3972, but it says issue 13 not found ? Sorry, I have no time to figure this out myself. | ||||
Steps To Reproduce | No idea. | ||||
Additional Information | This prevents me from seeing the actual bug 3972, so I set the severity to 'crash', if this is inappropriate, then feel free to change... | ||||
Tags | No tags attached. | ||||
Attached Files | mysql.txt (7,593 bytes)
mysql> describe mantis_bug_relationship_table; +--------------------+-----------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +--------------------+-----------------+------+-----+---------+----------------+ | id | int(7) unsigned | NO | PRI | NULL | auto_increment | | source_bug_id | int(7) unsigned | NO | MUL | 0 | | | destination_bug_id | int(7) unsigned | NO | MUL | 0 | | | relationship_type | int(2) | NO | | 0 | | +--------------------+-----------------+------+-----+---------+----------------+ 4 rows in set (0.00 sec) mysql> select * FROM mantis_bug_relationship_table WHERE source_bug_id=13 OR destination_bug_id=13; Empty set (0.00 sec) mysql> select * FROM mantis_bug_relationship_table WHERE source_bug_id=3973 OR destination_bug_id=3973; Empty set (0.00 sec) mysql> select * FROM mantis_bug_text_table WHERE id=3973; +------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | id | description | steps_to_reproduce | additional_information | +------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3973 | Sometimes (not always but nearly), when a connection between two hubs is lost, the link does not come back up even though it is set to autoconnect in the config file. The ircd "sees" the split (ie "Lost connection to ..." notice and SQUIT in the logs), but remains on its own indefinitely (10 hours in the last instance until someone reconnected manually). It seems that the problem builds up over time, ie. the first couple of disconnections after a restart/rehash are usually handled correctly (autotonnect kicks in), but later on, autoconnect just does not happen any longer. | | The only clue so far is: [Wed Dec 1 00:19:13 2010] - WARNING: Time jumped ~23 seconds ahead! (1291159130 -> 1291159153) [Wed Dec 1 00:19:13 2010] - [TimeShift] Resetting some timers! The server has ntpd running and has *not* skipped ahead itself. | +------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) mysql> select * FROM mantis_bug_table WHERE id=3973; +------+------------+-------------+------------+--------------+----------+----------+-----------------+--------+------------+------------+-----+-------------+-------+-----------+----------+---------+------------------+-------+------------+------------+-------------------------------------------------+-------------------+--------+----------------+-------------+----------------+----------+--------------+ | id | project_id | reporter_id | handler_id | duplicate_id | priority | severity | reproducibility | status | resolution | projection | eta | bug_text_id | os | os_build | platform | version | fixed_in_version | build | profile_id | view_state | summary | sponsorship_total | sticky | target_version | category_id | date_submitted | due_date | last_updated | +------+------------+-------------+------------+--------------+----------+----------+-----------------+--------+------------+------------+-----+-------------+-------+-----------+----------+---------+------------------+-------+------------+------------+-------------------------------------------------+-------------------+--------+----------------+-------------+----------------+----------+--------------+ | 3973 | 2 | 6352 | 0 | 0 | 30 | 60 | 30 | 10 | 10 | 10 | 10 | 3973 | Linux | 2.6.22.19 | x86 | 3.2.8 | | | 0 | 10 | Autoconnect link does not reconnect after split | 0 | 0 | | 7 | 1291856436 | 1 | 1291856436 | +------+------------+-------------+------------+--------------+----------+----------+-----------------+--------+------------+------------+-----+-------------+-------+-----------+----------+---------+------------------+-------+------------+------------+-------------------------------------------------+-------------------+--------+----------------+-------------+----------------+----------+--------------+ 1 row in set (0.00 sec) | ||||
There may be a reference to bug 13 (#13) in the text of the bug. This shouldn't crash the system though. |
|
This curios behaviour might be caused by wrong customization. Maybe another hint to find the problem: |
|
The 'has patch' is listed in the issue list, or at least.. so it seems to me. I've attached some mysql info in mysql.txt. If you need any other information from a table, just ask. I really have no idea what the cause of this is. On a sidenote, the same bug was resubmitted as 3973 as well.. same issue. It becomes crashable immediately on submit AFAICT. Ok, just tested, and if I copy-paste the exact text, I can create (yet another) crashable bug report. bleh... ok I've found it, this causes it to crash: ~ followed by the number 23 in the additional information field [havent checked others] causes this error (strangely, for refering to 13 instd of 23). EDIT: the same text in a comment causes a crash as well. Also if I use for example the number 22 I get an error about 19.. interesting ;) |
|
~23 means: Search for note with id 23. If there is none, display ~23. If there is a note with id 23, display a link to the issue where note 23 exists. Did you install any other plugin and / or did you write any custom functions and / or change source code of MantisBT? |
|
Have you tried reproducing it? It crashes in string_process_bugnote_link() indeed. I've no customizations except for the 'has patch' thing, and I always upgrade mantis by moving the current mantis to a different directory, then extracting a fresh mantis, and copying over the few custom files (config_inc.php) from old to new.. no files modified. EDIT: FYI, I've now hacked string_process_bugnote_link to return the string, so those ~ refs aren't processed. I don't want to disable # |
|
I tried existing and non existing bugnote id's but I was not able to reproduce the issue that simple way. |
|
syzop: can you check your mantis_bugnote_table for the note with id=23 and confirm that the bug_id column refers to an existing bug? I.e., does I fabricated such an orphaned bugnote in my local installation (which was created just to poke at this bug) and got an interesting result. The bugnote text referring to the orphaned bugnote 0000009:0000010, which I entered as |
|
@ohnobinki - the error you see is due to the fact that there is no error checking for existence of the bug id retrieved from the bugnote's id, so if the bug does not exist then the callback function is (obviously) not able to retrieve the project id. @syzop, I have the feeling your issue is caused by data corruption, but I have not been able to reproduce your original issue. As you mentioned having hacked your system and not provided any updates here since 2 years, I'm resolving this. |
|
Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch |
|
MantisBT: master 79fc861e 2012-08-17 04:16 Details Diff |
Bugnote '~' processing may produce error if bug does not exist This error case is a bit far-fetched, and should normally not occur unless there is some data corruption. If referencing an existing bugnote whose parent bug is not in the database, the callback function cannot retrieve the project_id, so error 403 is triggered. The callback functions have also been reformatted for better readability Fixes 0012580 |
Affected Issues 0012580 |
|
mod - core/string_api.php | Diff File | ||
MantisBT: master-1.2.x 6e29c1eb 2012-08-17 04:16 Details Diff |
Bugnote '~' processing may produce error if bug does not exist This error case is a bit far-fetched, and should normally not occur unless there is some data corruption. If referencing an existing bugnote whose parent bug is not in the database, the callback function cannot retrieve the project_id, so error 403 is triggered. The callback functions have also been reformatted for better readability Fixes 0012580 |
Affected Issues 0012580 |
|
mod - core/string_api.php | Diff File |