Bug Friday - win & suffer with u-he!

Official support for: u-he.com
Post Reply New Topic
RELATED
PRODUCTS

Post

Did you try to run it with valgrind or duma?

Post

abique wrote:Did you try to run it with valgrind or duma?
Not yet, but we're going to check this out. Sascha used valgrind before, so I guess it's possible to use with a plug-in.

Other than that we have an evaluation copy of CodeSonar. We're going to test it against 3 bugs that we had recently. If it finds those (and maybe more) then it's possibly money well spent.

Unfortunately though I think that the way our project is set up doesn't really go well with static code analysis. We shall see...

- Urs

Post

Also llvm & clang has static code analysis, I think that Google fixed a lot of bugs in free software with it.

Has the bug always been there? Did you try to bisect your revision history to find it?

Does it happens because of the GUI or the bug is in the engine?

Is it related to concurrency and initialization?

Post

Urs wrote:
abique wrote:Sascha used valgrind before
Not quite, it was BoundsChecker ;)
Sascha Eversmeier
drummer of The Board
software dev in the studio-speaker biz | former plugin creator [u-he, samplitude & digitalfishphones]

Post

abique wrote:Also llvm & clang has static code analysis, I think that Google fixed a lot of bugs in free software with it.
Way off-topic - I was drinking the kool-aid on Google Go (actually, convincingly open-source) over the holiday weekend, IMHO it's as worth following as anything that isn't C or Java. Concurrency, initialization, pointer arithmetic sorts of things have all been thought through very competently and with an old-school 'We've got Ken Thompson on the team' sort of feel. I don't think it's true of VST development the way it is for anything around web development but if one believes that better development tools can improve the eventual outcomes in user/consumer space, I was impressed.

Good luck on the bug hunting - sounds like a pure distillation of frustration :?

Post

Well, we had a bit of a head scratch yesterday. AUValidation fails whenever we build something with optimisations turned off. That's kind fo weird, and we're looking into this.

We've started evaluating CodeSonar. It finds bugs, indeed. Not sure yet if that kind of dough is justifyable for us, but we'll certainly think about it.

That said, we will shortly have a build of Satin that has no excessive debug checks except for the Bug Friday one. This will tell us whether it's fixed or whether the probes have altered the result. And of course we yet have to find out what's causing tracks to be muted.

Post

Interesting how they don't have a price stated on their site. Is it worth a kidney or more? Or less? :D

Post

How better than valgrind, duma, clang-analyser is it?
Did you try them?

Post

EvilDragon wrote:Interesting how they don't have a price stated on their site. Is it worth a kidney or more? Or less? :D
I too went looking for a price out of curiosity and noticed that too.
As they say if you have to ask..... :-)
rsp

Post

abique wrote:How better than valgrind, duma, clang-analyser is it?
Did you try them?
Clang doesn't find a thing in our code. Found a single uninitialised variable - in an external lib in a function we don't use. It seems to be C/ObjC only.

Valgrind finds a few things in runtime, but it's a bit puzzled by the symbols. Doesn't show line numbers. Maybe can't cope with debugging a plugin within a host. Need to investigate more.

Haven't treid Duma yet.

CodeSonar finds bugs. Really. The pricing is awkward, from a phone call with their reseller I'd estimate a 5-digit sum in Euros for an unlimited number of seats. Depends on size of the project it seems.

- Urs

Post

Theres also coverity, we run it on a weekly basis on our code base here, though I have no clue on the licensing prices.

Its more of a code checker than debugger/analyser though, but it will pick out bad paths, nulls, etc. Being an embedded shop we have to stick with core files, occasional gdb, and my favorite the printf/printk/logging

Post

In a spur of the moment kind of way i quickly decided to jump on this and try to help out. I grabbed what i think was the current build at that time (Couple of days ago, rev. 2086), made a quick 4bar midi session, put satin vst3 on it, saved and reopened.
I haven't received any logs on my desktop. My track does not give any sound. I added another track, chose the Satin(x64) version, copied midi part, same synth (jp6k) same preset, and that works great. I can see the GUI updating as if Satin is receiving audio. Here's the funny part: I replaced Satin VST3 with Satin(x64) and still nothing. Not even dropping it from the channel insert helped at all. The track gives no sound. I changed back to VST3 version, no sound. I copied the entire track, no sound on either of the two.

This is Cubase Elements 7 on Win8 64bit os and host. Dunno if this helps at all..

EDIT::
I forgot to mention why i haven't said anything before:
i got caught up in work after this and haven't had a chance to properly test things out untill now

Post

valgrind has many modules, and can demangle & show line number. Yet you need debug info. Did you build with -g -O0?

Post

abique wrote:valgrind has many modules, and can demangle & show line number. Yet you need debug info. Did you build with -g -O0?
That's where it got weird: -O0 crashes AUValidation :shock:

Post

ezelkow1 wrote:Theres also coverity, we run it on a weekly basis on our code base here, though I have no clue on the licensing prices.

Its more of a code checker than debugger/analyser though, but it will pick out bad paths, nulls, etc. Being an embedded shop we have to stick with core files, occasional gdb, and my favorite the printf/printk/logging
The third step on their trial application page is "We come to you". I guess it's even more expensive than the others... :cry:

Post Reply

Return to “u-he”