After having worked quite a bit with KiCad to layout PCBs for own manufacturing I now wanted to order some professional prototype boards from allpcb. So I plotted Gerber files of my project. When inspecting the result of the back copper layer with GerbView I noticed a quite long straight line, that is definitively not part of my layout:
I played around a bit with various Gerber plot options but the error remains. Any Idea of what this could be? I’m on KiCad 5.0.0-3
By the way, this is what my Layout should look like:
Edit: Changed the screenshot as the first one contained irritating errors that had nothing to do with my actual problem 
Might be this bug:
Solution: look at your file and search for some element that has very strange coordinates. Delete said element using a text editor, (Make a backup first)
It may be a bug in pcbnew or gerbview. Try another viewer (gerbv). If it persists, it’s in pcbnew which has either generated wrong gerber or added something to the pcb file or internal representation. If the problem is in the pcb file you can do as Rene suggested. It’s possible to edit gerbers manually, too, but much more difficult.
Adding to the above, you could also zoom into one end, to see what that ‘belongs to’, then try delete of that trace/outline etc, and see if the error goes away.
The bug above refers to Text, but also alludes that you can have extreme ‘accidental’ numbers in a design file, that push to the database limits.
If you can have one .pcbnew file that is ok and one that fails, you can then run a compare on the two files, & finding such extreme numbers should be simpler.
Thanks for your responses so far.
I tried opening the Gerber file in another viewer, the error persists. I went on finding the end of the line in pcbnew as @PCB_Wiz suggested, removed the wire and then found something strange. Look at the screenshot below:
The upper ratsnest line doesn’t go straight from the via to the corresponding pin but has a little hook that can’t be removed. Exporting the Gerber in this state shows that the unwanted line starts just here. However, there is nothing in the layout I can select to delete it, so I’m a bit confused on how to fix this. Rebuilding the Layout would be the worst option 
Try to find the exact coordinates of that “hook” point. Open the pcb file in a text editor and search for that coordinate (even partial) and see what’s there. If the design isn’t secret, you can even post the whole file here and we can look at it.
Can you share your pcb_new file?
Great, that did the trick, found the coordinate and with it a strange looking super big negative number. Just deleted that line from the file in the text editor, re-routed the track and after that, everything now looks as expected.
Now even if I’m ready to go now, I’d like to know if this is a known or unknown bug or an error from my side? If it’s a bug, should I create a bug report somewhere to help the developers fixing it?
If and only if it’s only pcbnew’s own “engine” which has touched that file it’s probably a bug. Have you used any python scripts or something like that?
Do you use version control so that you could find a point in time when it appeared, and the situation before and after?
Can you still give the whole file here? It may help finding the reason. If it’s a bug it may be important to report it and find the reason.
EDIT: at least paste here the whole line from the file with some context.
It might be related to the but i linked above. My side of reporting it only dealt with what happens once a test is already at that location. We never found out how the original reporter got their file to that stage. (So the devs mainly focused on the result of the bug not the origin)
Nope, just pcbnew was used. I did the whole layout in one run, so although there is version control, there is just this one version of the file. I could dig around in my time machine backups when I’m back home, maybe it stored a intermediate version.
And yes, I can give you the file, as this will become part of the rework of an open source project anyway You find the version with the error here
The line I deleted is 2613
What value was the ‘strange looking super big negative number’ ?
Was it similar to the -2147.483648 mm mentioned in the bug link above ?
That appears to be a database clipping limit.
That depends on what created that. Do you have older copies of the file, you can gerber plot to check when that appeared ?
Manually editing files can cause unforeseen problems, but usually not quite like this.
It may be some SW operation is failing with a MIN error result ?
I’d suggest more frequent saves, of variant versions, and at least this issue is easy to see 
Just looked back at the file (link in my post above) and it is in fact -2147.483648. However it primarily looked suspicious to me, as it was out of range compared to all surrounding coordinates
Exactly that, so it must be the same bug or at least somehow related.
Yes, when I edit the file to this, just to poke it a little,
(segment (start 174.498 104.013) (end -2999.483648 104.013) (width 0.25) (layer B.Cu) (net 38))
and load and save it becomes this (load gives no errors, but it is not centered)
(segment (start 174.498 104.013) (end -2147.483648 104.013) (width 0.25) (layer B.Cu) (net 38))
so it seems pcbnew has some natural clipping to the MIN value, should it hit anything less ?
(ie it does not wrap, instead clips) - Still, a specific number is easier to find.
It is sounding less ‘external’, and more ‘internal’…
Perhaps a new build can take any PCB load that finds co-ordinates outside, or right on, the MIN/MAX limits, and issue a warning ?
That might make it easier to zero-in on a prior editing action that may trigger this bug ?
As described in the bug report, the natural clipping is the result of using 32bit signed (twos complement) numbers.
Such a number can hold the values -2^31 … 2^31-1 (So -2147483648…2147483647)
The problem is that being near that value risks having a so called overflow. Integer arithmetic is quite funny. If you add one to the maximum representable value you get the minimum value (so 2147483647+1 results in -2147483648). This is why you get such a long line in the gerber output if you trigger that bug. (the line end is at the maximum coordinate, but the round end extends beyond that.)
The fix proposed by the devs is to limit the drawing size of pcb_new to a value much smaller than the maximum that can be represented by the number format. The open question is how to handle flies that already have a larger design in them. (See the linked bug report for more details)
As well as my tests above, I find that Edit.CleanupTracks&Vias.DeleteDanglingTracks removes a number of trace segments from that net 38.
Yes, but if you see my test above, that classic wrap does not happen on File load, instead it clips.
Or, how to catch a bug that might create such co-ordinates.
Right now, such files load silently, which is not so good for tracing what causes this.
Smarter would be to issue a warning when the Clip action is taken, or limit value is seen.
ie that may be supposed to be ‘legal’, but it does not display like it plots, so clearly limit-cases are marginal.
As a Clip action is causing a loss of data or other unexpected behaviour, I agree that there really should be an immediate warning that something has gone wrong. I cannot think of a circumstance where clipping is an acceptable result to be safely hidden.
