-
Notifications
You must be signed in to change notification settings - Fork 13
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
Fix readLength() return type error #22
Conversation
Btw, are the tag numbers and chunk length etc. in XDF format always non-negative? Would there occasionally be -1 for example? I didn't find enough details in the specs. Not sure about the use of |
Yes, it's not mentioned explicitly, but the idea is that tag numbers start with 1 and increase. Chunk length cannot be less than zero, AFAIK we don't use any special indicator (such as -1) to flag something unusual. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
The chunk type is defined as The return type of readLength is already Could you upload the problematic file somewhere or show in a debugger that a smaller type gets promoted incorrectly, i.e. the return value of |
One additional thing: I've compiled the code with clang 9 ( |
@tstenner for me on a Win 10 machine opening any XDF file using SigViewer would hang. I already turned off my laptop so cannot show at the moment, but I made extensive tests earlier and am pretty sure this is the cause. I can provide some sample XDF files tomorrow if needed. |
I use MinGW 5.3. Problem likely related to platform specific compiler. |
Does MinGW produce 64 bit binaries? |
The version @Yida-Lin is using doesn't - or at least I assume, because we've been building SigViewer with the 32bit MinGW version ever since. Qt has started to ship a 64bit version only recently so I haven't made the switch yet. |
Then there will be fun type conversions from The Qt installer ships the 64 bit version of MinGW 7.3, so this could be a good time to switch. |
@tstenner Good point, this sounds like could be the cause. So I had to use 32 MinGW 5.3 for a reason; MinGW 7.3 supports 64 bit but as libbiosig doesn't build on Windows (I only have a pre-built 32 bit lib) I had to use MinGW 5.3 in this case. I would argue that this change is necessary to avoid unexpected results - and to have backward compatibility. Talking about code simplicity and beautification - I know this library is quite messy, there is a lot of things that can be optimized. I will try to do that in the following days, but of course, in separate PRs. |
I keep forgetting this, thanks for the reminder. Do you think we can use the prebuilt Win64 binary libbiosig? http://biosig.sourceforge.net/download.html |
Sounds good Clemens, I will give 64 bit libbiosig a try tomorrow. |
I have a modified biosig (+CMake) folder for biosig on Windows somewhere to test if it's possible to build it with MSVC, but the C support for MSVC is atrocious. Building on Windows with MinGW requires some minor modifications, but it's possible:
|
This seems like a git log instead of an actual CMake file. We can discuss more on migrating to 64 bit, but IMO this PR is still necessary; it took me quite a while to trace the bug down, leaving it the way it is might cause some other developers losing time as well unnecessarily. |
I believe that it changes something, but I don't see how it fixes the underlying bug. I've added a simple xdf loader in #26 that will fail to load your files if it's really a libxdf bug. |
Hi @cbrnr is this bug reproducible on MacOS? |
Should I test this with the current master or this branch? |
@cbrnr Yes that would be great |
Nope, doesn't freeze on macOS, I can open XDF files. |
So how do we proceed? I've lost track of the current status. Which bugs have been squashed and which bugs still remain to be solved? |
Not too sure; seems only Win 32 platform is affected. For me it's probably easier to merge this one as later I don't have to manually make these changes when I debug something. Also if somebody (other than SigViewer, not sure whether there is any) on Win 32 uses this library, that will cause problems as well. But as we don't provide SigViewer Win 32 release, I am also OK if this is left not merged. Btw @cbrnr this is just a single bug, which is only reproducible on Win 32 so far and causes the application to freeze when opening any XDF file. I think I earlier tried 64bit libbiosig but it did not compile. |
Alright, if this PR doesn't have any negative side effects please go ahead and merge. |
Hi @tstenner would you be OK with this? |
It doesn't have any negative side effects (other than an additional commit in the git history), because it doesn't have any real effects. You can check this with |
This is a bug that causes SigViewer to hang. The return type of the
readLength()
must beuint64_t
. Implicitly casting it causes errors.