Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bugfixes #1456

Merged
merged 8 commits into from Aug 5, 2015
Merged

Bugfixes #1456

merged 8 commits into from Aug 5, 2015

Conversation

@allisonvacanti
Copy link
Contributor

@allisonvacanti allisonvacanti commented Jul 16, 2015

@doutriaux1 @chaosphere2112 @aashish24 @sankhesh

This branch has some bugfixes that were #1450, but since that is delayed due to stability issues, I've pulled some of the useful commits out of it so they can be merged sooner.

Once this is merged, #1450 needs to be rebased on master and when the memory leaks are fixed, #1450 can be merged.

@aashish24
Copy link
Contributor

@aashish24 aashish24 commented Jul 21, 2015

@dlonie can you update this branch? Also, @doutriaux1 can you approve this branch soon?

@allisonvacanti
Copy link
Contributor Author

@allisonvacanti allisonvacanti commented Jul 21, 2015

Added it to my list -- When I'm back on UVCDAT I'll do it first thing.

On Tue, Jul 21, 2015 at 10:28 AM, Aashish Chaudhary <
notifications@github.com> wrote:

@dlonie https://github.com/dlonie can you update this branch? Also,
@doutriaux1 https://github.com/doutriaux1 can you approve this branch
soon?


Reply to this email directly or view it on GitHub
#1456 (comment).

@allisonvacanti
Copy link
Contributor Author

@allisonvacanti allisonvacanti commented Jul 21, 2015

Rebased on current master.

@aashish24
Copy link
Contributor

@aashish24 aashish24 commented Jul 24, 2015

@doutriaux1 this looks good to me. However, you should review it so that we can get it merged soon.

@aashish24
Copy link
Contributor

@aashish24 aashish24 commented Jul 24, 2015

👍

@doutriaux1
Copy link
Contributor

@doutriaux1 doutriaux1 commented Jul 24, 2015

will test on mac and ubunutu on monday

@aashish24
Copy link
Contributor

@aashish24 aashish24 commented Jul 24, 2015

Okay, thanks!

@doutriaux1
Copy link
Contributor

@doutriaux1 doutriaux1 commented Jul 27, 2015

@dlonie looks like we need a rebase.

@doutriaux1
Copy link
Contributor

@doutriaux1 doutriaux1 commented Jul 27, 2015

@dlonie just rebased don't worry about it. Testing on ubuntu now

@doutriaux1
Copy link
Contributor

@doutriaux1 doutriaux1 commented Jul 27, 2015

@doutriaux1
Copy link
Contributor

@doutriaux1 doutriaux1 commented Jul 27, 2015

ok fixed the rebase issue, much better now:
ubuntu: https://open.cdash.org/viewTest.php?onlyfailed&buildid=3925468
RH6: https://open.cdash.org/viewTest.php?onlyfailed&buildid=3925467

@sankhesh @dlonie looks like label are now behind isolines, not great, which one of you should look into this?

@durack1
Copy link
Member

@durack1 durack1 commented Jul 27, 2015

@doutriaux1 looks like the date of the data indexed has changed - 1979/9/1 vs 1979/3/1 as seen here
timestep

@allisonvacanti
Copy link
Contributor Author

@allisonvacanti allisonvacanti commented Jul 28, 2015

Looks like an issue on your machine. All of the isoline tests pass on mine with the rebased changes, and buildbot is happy with it too. The only failure I see is a style issue in the rebased code: https://open.cdash.org/viewTest.php?onlyfailed&buildid=3925493

Also, neither buildbot nor I am getting any of these errors/warnings:

Processing error for quick,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for map,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for polar,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for alaska,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for albersequalarea,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for lambert,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for mercator,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for polyconic,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for equidconica,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for transversemercat,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for stereographic,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for lambertazimuthal,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for azimuthal,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for gnomonic,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for orthographic,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for genvertnearper,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for sinusoidal,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for equirectangular,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for miller,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for vandergrinten,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for hotin,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for robinson,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for spaceoblique,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for interruptedgoode,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for mollweide,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for interruptedmollw,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for hammer,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for wagneriv,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for wagnervii,Gi: 'Gi' object has no attribute '_textcolor'
Processing error for oblated,Gi: 'Gi' object has no attribute '_textcolor'

They are present in all of the failing tests on your machine, but not anywhere else. Not sure what's going on with your system.

@doutriaux1
Copy link
Contributor

@doutriaux1 doutriaux1 commented Jul 28, 2015

I’m more worried about this being an issue with OS I will try on another RH then.

@doutriaux1
Copy link
Contributor

@doutriaux1 doutriaux1 commented Jul 28, 2015

@sankhesh do you have a RedHat machine accessible, I get loads of errors on another RedHat see:
https://open.cdash.org/viewTest.php?onlyfailed&buildid=3927352

@sankhesh
Copy link
Contributor

@sankhesh sankhesh commented Jul 28, 2015

@doutriaux1

I don't. I can try to fire up a CentOS6 VM.

@durack1
Copy link
Member

@durack1 durack1 commented Jul 28, 2015

@doutriaux1 is this hint maybe partially why the error with #1329? In particular I'm noting that it's picking up a lineage from the 2.2.0rc1 branch rather than 2.2.0

Successfully updated your environment to use UVCDAT
(changes are valid for this session/terminal only)
Version: uvcdat-**2.2.0rc1**-257-g9b27735
Location: /export/doutriaux1/build/install
libGL error: failed to open drm device: No such file or directory
libGL error: failed to load driver: r600
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  72 (X_PutImage)
  Serial number of failed request:  65
  Current serial number in output stream:  73

@sankhesh
Copy link
Contributor

@sankhesh sankhesh commented Jul 31, 2015

Folks,

Here is a CentOS 6.6 build of master branch that shows the same errors as reported by @doutriaux1. I don't think these issues are related to #1456.

Furthermore, I ran into #1192 as well.

@doutriaux1
Copy link
Contributor

@doutriaux1 doutriaux1 commented Aug 3, 2015

@sankhesh ok that confirms my suspicion it's OS-based. @sankhesh can you give access to your CentOS VM to @dlonie ?

@sankhesh
Copy link
Contributor

@sankhesh sankhesh commented Aug 4, 2015

This definitely seems like a VCS issue. I suspected it to be an OpenGL related issue, but the VTK dashboard was clean on this machine.

https://open.cdash.org/viewTest.php?onlypassed&buildid=3938803

I still get 23 test failures with CDAT_BUILD_GUI=OFF on the same machine with UV-CDAT:

https://open.cdash.org/viewTest.php?onlyfailed&buildid=3938788

@allisonvacanti
Copy link
Contributor Author

@allisonvacanti allisonvacanti commented Aug 4, 2015

Since these failures happen on master, without GUI, and VTK works fine on this OS, these errors don't seem to be related to this branch.

Since this branch works everywhere else and introduces no new failures on RedHat/CentOS from the ones that we see on master, can this get merged?

@aashish24
Copy link
Contributor

@aashish24 aashish24 commented Aug 4, 2015

@dlonie I agree. It seems to be related to some other factor that is more related to GL/OS issue. Can yo file a bug? @doutriaux1 what you think?

@doutriaux1
Copy link
Contributor

@doutriaux1 doutriaux1 commented Aug 4, 2015

@aashish24 I don't think anything, all I know is we can't merge this branch until it passes on our officially platforms...

@allisonvacanti
Copy link
Contributor Author

@allisonvacanti allisonvacanti commented Aug 5, 2015

@doutriaux1....if master is also failing on this platform, this branch is not causing the problem....

But whatever. I don't really care when/if this makes it in, but that argument makes no sense.

@aashish24
Copy link
Contributor

@aashish24 aashish24 commented Aug 5, 2015

@doutriaux1 I have to agree with @dlonie here. I think the bugs are not related to this branch unless I am missing something. Also, GL errors are happening because of machine and driver combination. We should file another bug for it.

@aashish24
Copy link
Contributor

@aashish24 aashish24 commented Aug 5, 2015

@doutriaux1 I looked at the code again. I don't see anything here that could cause GL errors. I highly recommend that we merge this branch as soon as possible. Call me if you have any doubts.

@doutriaux1
Copy link
Contributor

@doutriaux1 doutriaux1 commented Aug 5, 2015

all i'm saying is it doesn't pass on RH. Feel free to open another issue, fix the issue, merge back in this branch and then we can approve this one.

@allisonvacanti
Copy link
Contributor Author

@allisonvacanti allisonvacanti commented Aug 5, 2015

Like I said, I don't really care if we hold off on merging this, as long as you realize that enacting that policy while master is failing on RH means that any and all new PRs cannot be merged, so we're essentially freezing master until that is fixed.

@doutriaux1
Copy link
Contributor

@doutriaux1 doutriaux1 commented Aug 5, 2015

I do realize that. That's why it's important someone fixes it quickly.

@durack1
Copy link
Member

@durack1 durack1 commented Aug 5, 2015

@sankhesh @dlonie @doutriaux1 these errors:

Successfully updated your environment to use UVCDAT
(changes are valid for this session/terminal only)
Version: 2.2.0-242-g6da0879
Location: /home/kitware/Projects/uvcdat/bld/install
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  72 (X_PutImage)
  Serial number of failed request:  65
  Current serial number in output stream:  86

https://open.cdash.org/testDetails.php?test=359872924&build=3938788

Look awfully similar to the X11-related problems I was encountering a while back.. I wonder if with the redhat6.7 (and possibly CentOS) patches that have recently started being pushed, some X11-config issue has cropped up on these machines?

I've hit similar issues when using 8-bit vs higher colour modes on forwarding displays, the output of some of the failing test images look suspiciously low-bit to me..

I also wonder whether the data being indexed as noted above could also be an issue - it seems that the date is changing in some of these image tests

@doutriaux1
Copy link
Contributor

@doutriaux1 doutriaux1 commented Aug 5, 2015

@williams13 what do you think?

@durack1
Copy link
Member

@durack1 durack1 commented Aug 5, 2015

@sankhesh @dlonie @doutriaux1 I also noted a branch lineage difference with a few of these, so:

@doutriaux1 is building with a git hash: Version: **uvcdat-2.2.0rc1**-257-g9b27735

Whereas @sankhesh is building with a different hash: Version: **2.2.0**-242-g6da0879

I wonder if a test (and or the data) or the index of the data is different between these - there have certainly been cases where we've lost merged branches in the master/release tangle: #1329 and #1441

@doutriaux1
Copy link
Contributor

@doutriaux1 doutriaux1 commented Aug 5, 2015

@dlonie I'm going to try on master, I didn't realize it's happening there either. If it happens on master a swell then yes I'm ok to merge this one in.

@jbeezley
Copy link

@jbeezley jbeezley commented Aug 5, 2015

I think @durack1 is on to something. Google searches on the X_PutImage error all lead to color mode issues. In places where this is occurring, what is the output of xwininfo -root? I suspect the default X config on CentOS is setting the color depth to 8 bits for some (probably buggy) reason.

@doutriaux1
Copy link
Contributor

@doutriaux1 doutriaux1 commented Aug 5, 2015

ok lots of failure on master as welll.... merging this in so we can focus on fixing these errors. This means though that I'm going to focus mainly on setting up a buildbot server here so that we can have automatic testing of our officially supported platform AND more combinations of build modes.

doutriaux1 added a commit that referenced this issue Aug 5, 2015
@doutriaux1 doutriaux1 merged commit 21e26d0 into master Aug 5, 2015
3 checks passed
@doutriaux1
Copy link
Contributor

@doutriaux1 doutriaux1 commented Aug 5, 2015

@doutriaux1 doutriaux1 deleted the bugfixes branch Aug 5, 2015
@aashish24
Copy link
Contributor

@aashish24 aashish24 commented Aug 5, 2015

thanks @doutriaux1 +1 for @buildbot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

6 participants