BUG: check if vtrype is not INVALID

[mrc-sys]

BUG: Only access the value of si , if vrtype is not invalid. This prevents a SegmentationFault in the case of an invalid tag

PR Checklist

• [x] No API changes were made (or the changes have been approved)
• [x] No major design changes were made (or the changes have been approved)
• [x] Added test (or behavior not changed)
• [x] Updated API documentation (or API not changed)
• [ ] Added license to new files (if any)
• [ ] Added Python wrapping to new files (if any) as described in ITK Software Guide Section 9.5
• [ ] Added ITK examples for all new major features (if any)

Refer to the ITK Software Guide for further development details if necessary.

[jhlegarreta]

@mrc-sys Thanks for contributing to ITK :100: !

Can you please remove commit 4ed3b6fd187a733761217a4cbb52e9b81972f55d in the branch, as it is a duplicate of the latter b300ae27ad7e11e8b65c924fe1a6e5cd6d504046, this one having the appropriate style for an ITK commit? Thanks !

[mrc-sys]

@mrc-sys Thanks for contributing to ITK 100 !

Can you please remove commit 4ed3b6f in the branch, as it is a duplicate of the latter b300ae2, this one having the appropriate style for an ITK commit? Thanks !

Can you describe me, how to remove the commit? I am happy to get the later commit in the appropriate style....

[mrc-sys]

You're avoiding a segfault by hiding the symptoms. I suspect this creates an empty Data Element, this is not a desired behavior AFAIK.

If it´s possible to avoid the crash in a better way, I would prefer the better solution. But for now I have not found this better solution and this segfault is a showstopper for me.

[jhlegarreta]

Can you describe me, how to remove the commit? I am happy to get the later commit in the appropriate style....

You should rebase interactively using git rebase -i HEAD~2 then mark the commit to be deleted with d (for drop), exit with :wq, then continue the rebase with git rebase --continue, and it should be fine. Then you would git push -f origin {your_branch_name} to push to the repository.

[mrc-sys]

Can you describe me, how to remove the commit? I am happy to get the later commit in the appropriate style....

You should rebase interactively using git rebase -i HEAD~2 then mark the commit to be deleted with d (for drop), exit with :wq, then continue the rebase with git rebase --continue, and it should be fine. Then you would git push -f origin {your_branch_name} to push to the repository.

Can this be done in the github web-gui too?

[malaterre]

@mrc-sys

If it´s possible to avoid the crash in a better way, I would prefer the better solution. But for now I have not found this better solution and this segfault is a showstopper for me.

You'll need to provide us more detail on how to reproduce the segfault. Or simply dump part of the backtrace (eg. 'bt' under gdb).

[jhlegarreta]

Can this be done in the github web-gui too?

I don't know. I use the command line for these tasks. Sorry.

[dzenanz]

I don't think rebase can be done in GitHub WebUI. But it can be done in e.g. TortoiseGit and gitk.

[mrc-sys]

@mrc-sys

If it´s possible to avoid the crash in a better way, I would prefer the better solution. But for now I have not found this better solution and this segfault is a showstopper for me.

You'll need to provide us more detail on how to reproduce the segfault. Or simply dump part of the backtrace (eg. 'bt' under gdb).

I will try to reproduce the error again, but I have patched ITK 4.13.1 about 4 years ago (ubuntu 16.04) and the bug popped up again on porting our application to ubuntu 20.04 and ITK 4.13.3. As the patch solved the problem again and the source was not changed in the meantime, I have not tested without the patch again.

[thewtex]

Addressing style issues

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.