Opened 5 years ago

Closed 5 years ago

#17873 closed defect (fixed)

Segfault in iFUB

Reported by: dcoudert Owned by:
Priority: major Milestone: sage-6.6
Component: graph theory Keywords:
Cc: ncohen Merged in:
Authors: David Coudert Reviewers: Nathann Cohen
Report Upstream: N/A Work issues:
Branch: fe533dd (Commits) Commit: fe533ddc3b8533dc0c4c746ebc2a1fe0115b9e34
Dependencies: Stopgaps:

Description (last modified by dcoudert)

This patch resolve a segfault occuring in iFUB for graphs of order 1. It was due to an uninitialized variable in diameter_lower_bound_multi_sweep.

Change History (8)

comment:1 Changed 5 years ago by dcoudert

  • Branch set to public/17873

comment:2 Changed 5 years ago by git

  • Commit set to fa969aa33c8aeb6889f207e2fad6671b1b0436b5

Branch pushed to git repo; I updated commit sha1. New commits:

fa969aatrac #17873: resolve segfault in iFUB

comment:3 follow-up: Changed 5 years ago by dcoudert

  • Cc ncohen added
  • Description modified (diff)
  • Status changed from new to needs_review

There is something weird in my commit and I don't understand why. I have not modified the generic_graph.py file but the commit contains code from it O_o I'm sure I have created this branch starting from the develop branch (after a git trac checkout develop; git trac pull; git branch ifub; git checkout ifub; fix ifub problems and do test and docbuild; git commit...; git trac push 17873). Any idea on how to resolve this?

David.

comment:4 in reply to: ↑ 3 Changed 5 years ago by ncohen

Hello !

Any idea on how to resolve this?

Well, I do not understand hwo you got there either. Your branch seems based on the latest develop indeed, but your must have had some changes in generic_graph when you ran this 'pull'. Either way none of that is really a problem. Here is what you should do:

1) "Break" your last commit. Its content will become unstaged changes sage reset HEAD~1

2) At this moment you can do a git checkout generic_graph.py. This will discard any change in generic_graph.py. In particular there are <<<<<<< and >>>>>>> in there that probably come from a failed merge.

3) When you are satisfied with the result, create the commit again in the usual way

4) As you modified a commit, technically you rewrote history. When you push your commit again you will have to use a -f flag.

In general, if you call 'tig' more frequently to look at your commits and diff you should have less troubles with git.

I am in the train right now, a bit after Avignon. God, it feels good to see this warm sunlight everywhere. It feels more like home than any other place.

Nathann

comment:5 Changed 5 years ago by git

  • Commit changed from fa969aa33c8aeb6889f207e2fad6671b1b0436b5 to fe533ddc3b8533dc0c4c746ebc2a1fe0115b9e34

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

fe533ddtrac #17873: fix bug in iFUB

comment:6 Changed 5 years ago by dcoudert

THANKS A LOT !!!

So the patch is ready to be reviewed. Note that I have not changed the first test of the diameter method from if n==0 to if n<=1, but we can do it as well to save time.

David. PS: current weather in Nice is not so perfect, we have some clouds ;)

comment:7 Changed 5 years ago by ncohen

  • Reviewers set to Nathann Cohen
  • Status changed from needs_review to positive_review

Well. Saving time for instances of size 0 is cool, but I seriously hope that it will not be the bottleneck anywhere. This fix is good, as the lowest level method does not rely on some assumption made by the function which calls it. Good to go, thanks !

Nathann

comment:8 Changed 5 years ago by vbraun

  • Branch changed from public/17873 to fe533ddc3b8533dc0c4c746ebc2a1fe0115b9e34
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.