In my hundreds of submissions, this is my first time encountering this Singular Iterator Runtime Error. In my submission 86437246, after passing the first few cases and when it encounters a relatively bigger input, the program exits with a RE. After looking at the diagnostic hints, I think it has something to do with singular iterators ( which is sort of equivalent to uninitialized pointers ), though I couldn't pinpoint where. But if I were to make a guess, I would say vector< pair< int, int > > which[1050]
should be the source of the problem as after using some alternatives for it, I managed to get my solution accepted (86437933).
It would be very helpful if someone can throw some light on where I went wrong, so that I could avoid this in my future submissions.
**UPD:- ** It is a normal out of bounds error. Increasing the size of vis
array takes care of it. Corrected submission — 86473660. Thanks WAontest2
Thanks a lot!
This is some kind of out-of-bounds issue. It might be in
pair< int, int > u = q.front();
, since the code that implements q.front() might use iterators.Compile your code with the flags
-ggdb3 -D_GLIBCXX_DEBUG
. Then run the code under gdb and set a breakpoint for abort usingbreak abort
command in gdb. It will break when the singular iterator error happens. Then you can check the lines where it happens.I did think of using a debugger, but the program crashes only for certain inputs, which makes things harder. The queue might not be the problem because, as I am doing the same operations on the queue in my accepted solution.
Could out of bounds result in this RE? Won't it exit with SIGSEGV ?
It should have given SIGSEGV , since the issue was out of bounds access. I have no idea at all. Please tell me as well if you figure out the issue.
The runtime error was probably due to the out of bounds access of the vis array. I changed it's size and the solution passed on test 14 but now it's getting TLE on test 17. I haven't read the question (it kinda seems like out of my range ) so can't help with the TLE part. 86470621
Seriouly? Ouch, I spent so much time debugging. Yeah, now it makes sense, I made the bound too tight. The TLE part is because of "endl". I should have used '\n' instead. Anyway, thanks a lot. But, usually when it is out of bounds, the CF system says it is out of bounds. I don't why it didn't in this case.