Inkscape gets hang with "Join selected endnodes..."

Reproduced with Inkscape 0.48 and 0.48+devel r10014 on OS X 10.5.8

Not reproduced with Inkscape 0.47 on OS X 10.5.8
(0.47 doesn't accept more than two nodes for 'Join selected endnodes with new segment').

I reproduced this as well

$ dpkg -l inkscape | tail -1
ii inkscape 0.48.0-1ubuntu1 vector-based drawing program
$ lsb_release -d
Description: Ubuntu 10.10

Like the traces here, the trouble was getting stuck in the weldSegments method. I looked at the method and something did not look right to me, so I added line 439 below, the printf method. Here is the relevant code, which includes one line by me, line 439 with the printf -

src/ui/tool/path-manipulator-cpp:

   398 /** Remove nodes in the middle of selected segments. */
   399 void PathManipulator::weldSegments()
   400 {
[...]
   406 unsigned num_selected = 0, num_unselected = 0;
[...]
   424 // Work loop
   425 while (num_selected > 0) {
[...]
   431 // note: this is initialized to zero, because the loop below counts sel_beg as well
   432 // the loop conditions are simpler that way
   433 unsigned num_points = 0;
   434
   435 // find the end of selected segment
   436 for (sel_end = sel_beg; sel_end && sel_end->selected(); sel_end = sel_end.next()) {
   437 ++num_points;
   438 }
   439 printf("%u %u\n",num_selected,num_points);
   440 if (num_points > 2) {
[...]
   447 }
   448 sel_beg = sel_end;
   449 }
   450 num_selected -= num_points;
   451 }

The output inkscape gives when I run it is:

$ ./inkscape
3 2
1 2
4294967295 2

num_selected jumps from 1 to 4294967295. Why? Because num_selected is an unsigned number. Its lowest value is 0. Once its value was 1, subtracting more than 1 from num_selected would not result in a negative number - but a number more like 4294967295. So it will then go on in the loop endlessly, or at least what would seem endlessly. I seriously doubt the original coder had this in mind, especially with the comment that previously more than one node would not be accepted.

Browsing the code repository, the error is still in the latest commit to the bzr trunk (10032), meaning it has not been fixed since the 0.48.0 release I have.

@Dennis - thank you for further investigating!

@Krzysztof - could you take a look at this issue?

Fixed:
Trunk revision 12650
0.48 stable branch revision 9970