View Issue Details

IDProjectCategoryView StatusLast Update
0012580mantisbtbugtrackerpublic2014-09-23 18:05
ReportersyzopAssigned Todregad 
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version1.2.3 
Target Version1.2.12Fixed in Version1.2.12 
Summary0012580: Issue x not found (for bug y)
Description

Any idea what this is?
http://bugs.unrealircd.org/view.php?id=3972

The issue is 3972, but it says issue 13 not found ?

Sorry, I have no time to figure this out myself.
I did a quick grep on mysqldump data on both 3972 and 13, but it yielded no results (could have overlooked, though..).

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...

TagsNo tags attached.

Relationships

related to 0015721 closedgrangeway Functionality to consider porting to master-2.0.x 

Activities

thraxisp

thraxisp

2010-12-05 09:52

reporter   ~0027536

There may be a reference to bug 13 (#13) in the text of the bug. This shouldn't crash the system though.

atrol

atrol

2010-12-05 10:24

developer   ~0027537

This curios behaviour might be caused by wrong customization.
For example I see that you introduced a new status "has patch", but this new status does not appear in status color legend.

Maybe another hint to find the problem:
The generated error page http://bugs.unrealircd.org/view.php?id=3972 contains an empty <head> section
whereas the page of a really not existent issue produces a "normal" MantisBT error page
for example http://bugs.unrealircd.org/view.php?id=4789

syzop

syzop

2010-12-10 14:37

reporter  

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)
mysql.txt (7,593 bytes)
syzop

syzop

2010-12-10 14:49

reporter   ~0027582

Last edited: 2010-12-10 14:52

View 2 revisions

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 ;)

atrol

atrol

2010-12-10 15:57

developer   ~0027583

~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.
This is the default behaviour and should not cause a crash.
There is also the default setting to replace #<number> to a link to issue with id <number>
You can disable this behaviour by choosing page "Manage" -> "Manage plugins"
Click on link "MantisBT Formatting 1.0a"
Set "MantisBT Links ( Issue/Issuenote )" to "Off"
I am pretty sure that this will solve your problem, but I am still wondering when seeing your problem.

Did you install any other plugin and / or did you write any custom functions and / or change source code of MantisBT?

syzop

syzop

2010-12-15 06:05

reporter   ~0027608

Last edited: 2010-12-15 06:09

View 2 revisions

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 #

atrol

atrol

2010-12-15 11:42

developer   ~0027611

I tried existing and non existing bugnote id's but I was not able to reproduce the issue that simple way.

ohnobinki

ohnobinki

2011-03-08 19:06

reporter   ~0028390

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
SELECT * FROM mantis_bugnote_table WHERE bug_id=13;
give anything?

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 0000009:0000010'', was rendered as:
APPLICATION WARNING #403: Database field "project_id" not found.
0000009:0000010
''
...which seems to be a mishandling of my intentional database inconsistency ;-).

dregad

dregad

2012-08-17 11:25

developer   ~0032613

@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.

grangeway

grangeway

2013-04-05 17:56

reporter   ~0036174

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch

Related Changesets

MantisBT: master 79fc861e

2012-08-17 08:16:46

dregad

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 08:16:46

dregad

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

Issue History

Date Modified Username Field Change
2010-12-05 09:42 syzop New Issue
2010-12-05 09:52 thraxisp Note Added: 0027536
2010-12-05 10:24 atrol Note Added: 0027537
2010-12-10 14:37 syzop File Added: mysql.txt
2010-12-10 14:49 syzop Note Added: 0027582
2010-12-10 14:52 syzop Note Edited: 0027582 View Revisions
2010-12-10 15:57 atrol Note Added: 0027583
2010-12-10 15:57 atrol Assigned To => atrol
2010-12-10 15:57 atrol Status new => feedback
2010-12-10 16:00 atrol Assigned To atrol =>
2010-12-15 06:05 syzop Note Added: 0027608
2010-12-15 06:05 syzop Status feedback => new
2010-12-15 06:09 syzop Note Edited: 0027608 View Revisions
2010-12-15 11:42 atrol Note Added: 0027611
2011-03-08 19:06 ohnobinki Note Added: 0028390
2012-08-17 11:25 dregad Changeset attached => MantisBT master 79fc861e
2012-08-17 11:25 dregad Assigned To => dregad
2012-08-17 11:25 dregad Status new => resolved
2012-08-17 11:25 dregad Resolution open => fixed
2012-08-17 11:25 dregad Fixed in Version => 1.3.0-beta.1
2012-08-17 11:25 dregad Changeset attached => MantisBT master-1.2.x 6e29c1eb
2012-08-17 11:25 dregad Note Added: 0032613
2012-08-17 11:25 dregad Target Version => 1.2.12
2012-08-17 11:25 dregad Severity crash => major
2012-08-17 11:25 dregad Fixed in Version 1.3.0-beta.1 => 1.2.12
2012-08-17 11:25 dregad Severity major => minor
2012-11-10 18:54 dregad Status resolved => closed
2013-04-05 17:56 grangeway Status closed => acknowledged
2013-04-05 17:56 grangeway Note Added: 0036174
2013-04-05 19:23 grangeway Relationship added related to 0015721
2013-04-06 03:40 dregad Status acknowledged => closed
2013-04-06 07:23 grangeway Status closed => acknowledged
2013-04-06 09:22 dregad Tag Attached: 2.0.x check
2013-04-06 09:23 dregad Status acknowledged => closed
2014-09-23 18:05 grangeway Tag Detached: 2.0.x check