> <snip>

>>> Are you really trying to find the bug?

>> When I have the time to do so.  The problem hasn't occurred in any recent
>> use of the program, so it hasn't been a priority.

> I can see some risk in that approach.

It's not a matter of risk assessment. This program is strictly used in a
hobby setting. There can be lengthy stretches of time when I simply don't
have the time to pursue the hobby. When I do have the time, that time is
usually split between adding capabilities to the program and using the
existing capabilities of the program. Out of the dozens of functions
provided by the program, there is one that is known to cause the program
to crash under certain conditions. Repeatably. Unless a WRITE statement
is added in one particular spot. Then it's fine. Annoying, but finding out
why isn't at the top of the priority list at the moment.

By way of analogy, there was a time when Microsoft's "GSA Certified to be
Correct and Complete" Fortran compiler failed to run a DO loop properly
if the step size was a variable:

ISTEP = 15
DO I=0,90,ISTEP

I reported the bug, and Microsoft acknowledged the bug. In the next
release of the compiler, was it fixed? No. They were too busy adding
new features to satisfy the many rather than fixing bugs to satisfy the
one. You and I might not agree with that approach. Depends on the type
of risk you're willing to take. One approach risked having a buggy
compiler whose reputation might suffer enough to adversely affect sales,
while the other approach risked adding new features that would appeal to
a larger potential customer base and make more money. It's a gamble.

In my case, it's not like a spacecraft will crash into the surface of Mars
if I don't find the bug.

> While you're not seeing the bug's most obvious manifestation, you don't know if it's dropping
> a random value in a random place in memory. That can be harmless ... until it's not.

Hypothetical example: if I were writing an image manipulation program, and
one feature was to crop the size of the image, and the cropping caused the
program to crash, unless a WRITE statement was added to a particular spot
in a subroutine, simple inspection of the cropped photo might reveal that
the bug is harmless. Now, if the blue sky turned green in the cropped
photo, then the bug isn't harmless. But the original photo is still there,
unaffected.

> It sounded, at least when you first posted, like you had a mysterious bug that you could reproduce. There are maintenance
> programmers out there who would be thrilled to work on a bug like that. It offers a challenge and an unknown payback: Going into it,
> you don't know what's not going to go wrong once the bug is fixed.

Yes, the crash was absolutely reproducible. Yes, the addition of a WRITE
statement made the problem go away, which was fairly mysterious.

> When I was working, I lived for bugs like this. I'd come in to the office late and I'd sit there with a cup of tea and a chocolate
> bar and Bruckner's 7th Symphony on my boombox and I'd crank up the volume and there was nobody around to complain and I'd lose track
> of time and once in a while I'd walk around and see if the sun was up (management didn't usually give window offices to people who
> liked to work at night) and by the time the normal people rolled in around 8:00 AM I'd at least have a handle on what was going
> wrong and I could share the details with colleagues who were interested and a few who weren't and then I'd go home and try to get
> some rest, secure in the knowledge that I'd done my bit and that if nobody saw me again until the next day they wouldn't miss me
> because have you ever actually listened to Bruckner?

I have nine Bruckner CDs in my collection (Symphonies 4 through 9). I
have at least one musician friend who insists that once you're heard a
Bruckner symphony, you've heard them all. Lately, however, I've been
listening primarily to other composers. In particular, the "Shout"
movement from Omar Thomas' "Come Sunday" has captured my fancy, but it's
the Baylor rendition that brings it to life. The energy, the sheer joy
of music-making, on full display.

On 8/29/2022 6:18 AM, Dave Tholen wrote:
>> <snip>
>
>>>> Are you really trying to find the bug?
>
>>> When I have the time to do so.  The problem hasn't occurred in any
>>> recent
>>> use of the program, so it hasn't been a priority.
>
>> I can see some risk in that approach.
>
> It's not a matter of risk assessment.  This program is strictly used in a
> hobby setting.  There can be lengthy stretches of time when I simply
> don't
> have the time to pursue the hobby.  When I do have the time, that time is
> usually split between adding capabilities to the program and using the
> existing capabilities of the program.  Out of the dozens of functions
> provided by the program, there is one that is known to cause the program
> to crash under certain conditions.  Repeatably.  Unless a WRITE statement
> is added in one particular spot.  Then it's fine.  Annoying, but
> finding out
> why isn't at the top of the priority list at the moment.
>
> By way of analogy, there was a time when Microsoft's "GSA Certified to be
> Correct and Complete" Fortran compiler failed to run a DO loop properly
> if the step size was a variable:
>
>       ISTEP = 15
>       DO I=0,90,ISTEP
>
> I reported the bug, and Microsoft acknowledged the bug.  In the next
> release of the compiler, was it fixed?  No.  They were too busy adding
> new features to satisfy the many rather than fixing bugs to satisfy the
> one.  You and I might not agree with that approach.  Depends on the type
> of risk you're willing to take.  One approach risked having a buggy
> compiler whose reputation might suffer enough to adversely affect sales,
> while the other approach risked adding new features that would appeal to
> a larger potential customer base and make more money.  It's a gamble.
>
> In my case, it's not like a spacecraft will crash into the surface of
> Mars
> if I don't find the bug.
>
>> While you're not seeing the bug's most obvious manifestation, you
>> don't know if it's dropping a random value in a random place in
>> memory. That can be harmless ... until it's not.
>
> Hypothetical example:  if I were writing an image manipulation
> program, and
> one feature was to crop the size of the image, and the cropping caused
> the
> program to crash, unless a WRITE statement was added to a particular spot
> in a subroutine, simple inspection of the cropped photo might reveal that
> the bug is harmless.  Now, if the blue sky turned green in the cropped
> photo, then the bug isn't harmless.  But the original photo is still
> there,
> unaffected.
>
>> It sounded, at least when you first posted, like you had a mysterious
>> bug that you could reproduce. There are maintenance programmers out
>> there who would be thrilled to work on a bug like that. It offers a
>> challenge and an unknown payback: Going into it, you don't know
>> what's not going to go wrong once the bug is fixed.
>
> Yes, the crash was absolutely reproducible.  Yes, the addition of a WRITE
> statement made the problem go away, which was fairly mysterious.
>
>> When I was working, I lived for bugs like this. I'd come in to the
>> office late and I'd sit there with a cup of tea and a chocolate bar
>> and Bruckner's 7th Symphony on my boombox and I'd crank up the volume
>> and there was nobody around to complain and I'd lose track of time
>> and once in a while I'd walk around and see if the sun was up
>> (management didn't usually give window offices to people who liked to
>> work at night) and by the time the normal people rolled in around
>> 8:00 AM I'd at least have a handle on what was going wrong and I
>> could share the details with colleagues who were interested and a few
>> who weren't and then I'd go home and try to get some rest, secure in
>> the knowledge that I'd done my bit and that if nobody saw me again
>> until the next day they wouldn't miss me because have you ever
>> actually listened to Bruckner?
>
> I have nine Bruckner CDs in my collection (Symphonies 4 through 9).  I
> have at least one musician friend who insists that once you're heard a
> Bruckner symphony, you've heard them all.  Lately, however, I've been
> listening primarily to other composers.  In particular, the "Shout"
> movement from Omar Thomas' "Come Sunday" has captured my fancy, but it's
> the Baylor rendition that brings it to life.  The energy, the sheer joy
> of music-making, on full display.

I would join you in disagreeing with your friend; Bruckner symphonies
are not all alike. There's the seventh, and there's everything else. OK,
maybe the seventh and the eighth, and everything else. OK, I'm being
facetious.

As far as your program goes, here's one way to identify the bug and
assess its potential impact: Upload the code and some test data, and let
some of us nerds (a few of us are retired with too much time on hands)
try to reproduce the crash in our own environments (mine is Fedora with
gfortran) and hopefully figure out what's going on. If it's a hobby
project, you might not need a formal NDA, but you could still ask for
common courtesy and discretion and so on. You could share the upload
link with everyone or with individuals.

As far as Microsoft and their DO-loop bug, I'm tempted to be appalled,
but there are a couple of things to consider:

How long was the interval between your bug report and the next release?
If the release had passed the code-freeze point and the bug wasn't a
regression caused by something new in the release, I could understand
why they wouldn't want to delay the release until the bug could be fixed
and the fix could be verified. The new release could have fixed a number
of other bugs, and it might have done more than just add new features.

Was the bug fixed eventually? I can't imagine letting something like
that stay broken past the next maintenance release.

At my last job, I worked on embedded code that ran inside laser
printers. The tolerance for bugs was zero.

I also listened to Mahler symphonies late at night.

Louis

>>> <snip>

>>>>> Are you really trying to find the bug?

>>>> When I have the time to do so.  The problem hasn't occurred in any recent
>>>> use of the program, so it hasn't been a priority.

>>> I can see some risk in that approach.

>> It's not a matter of risk assessment.  This program is strictly used in a
>> hobby setting.  There can be lengthy stretches of time when I simply don't
>> have the time to pursue the hobby.  When I do have the time, that time is
>> usually split between adding capabilities to the program and using the
>> existing capabilities of the program.  Out of the dozens of functions
>> provided by the program, there is one that is known to cause the program
>> to crash under certain conditions.  Repeatably.  Unless a WRITE statement
>> is added in one particular spot.  Then it's fine.  Annoying, but finding out
>> why isn't at the top of the priority list at the moment.
>>
>> By way of analogy, there was a time when Microsoft's "GSA Certified to be
>> Correct and Complete" Fortran compiler failed to run a DO loop properly
>> if the step size was a variable:
>>
>>       ISTEP = 15
>>       DO I=0,90,ISTEP
>>
>> I reported the bug, and Microsoft acknowledged the bug.  In the next
>> release of the compiler, was it fixed?  No.  They were too busy adding
>> new features to satisfy the many rather than fixing bugs to satisfy the
>> one.  You and I might not agree with that approach.  Depends on the type
>> of risk you're willing to take.  One approach risked having a buggy
>> compiler whose reputation might suffer enough to adversely affect sales,
>> while the other approach risked adding new features that would appeal to
>> a larger potential customer base and make more money.  It's a gamble.
>>
>> In my case, it's not like a spacecraft will crash into the surface of Mars
>> if I don't find the bug.

>>> While you're not seeing the bug's most obvious manifestation, you don't know if it's dropping a random value in a random place in
>>> memory. That can be harmless ... until it's not.

>> Hypothetical example:  if I were writing an image manipulation program, and
>> one feature was to crop the size of the image, and the cropping caused the
>> program to crash, unless a WRITE statement was added to a particular spot
>> in a subroutine, simple inspection of the cropped photo might reveal that
>> the bug is harmless.  Now, if the blue sky turned green in the cropped
>> photo, then the bug isn't harmless.  But the original photo is still there,
>> unaffected.

>>> It sounded, at least when you first posted, like you had a mysterious bug that you could reproduce. There are maintenance
>>> programmers out there who would be thrilled to work on a bug like that. It offers a challenge and an unknown payback: Going into
>>> it, you don't know what's not going to go wrong once the bug is fixed.

>> Yes, the crash was absolutely reproducible.  Yes, the addition of a WRITE
>> statement made the problem go away, which was fairly mysterious.

>>> When I was working, I lived for bugs like this. I'd come in to the office late and I'd sit there with a cup of tea and a
>>> chocolate bar and Bruckner's 7th Symphony on my boombox and I'd crank up the volume and there was nobody around to complain and
>>> I'd lose track of time and once in a while I'd walk around and see if the sun was up (management didn't usually give window
>>> offices to people who liked to work at night) and by the time the normal people rolled in around 8:00 AM I'd at least have a
>>> handle on what was going wrong and I could share the details with colleagues who were interested and a few who weren't and then
>>> I'd go home and try to get some rest, secure in the knowledge that I'd done my bit and that if nobody saw me again until the next
>>> day they wouldn't miss me because have you ever actually listened to Bruckner?

>> I have nine Bruckner CDs in my collection (Symphonies 4 through 9).  I
>> have at least one musician friend who insists that once you're heard a
>> Bruckner symphony, you've heard them all.  Lately, however, I've been
>> listening primarily to other composers.  In particular, the "Shout"
>> movement from Omar Thomas' "Come Sunday" has captured my fancy, but it's
>> the Baylor rendition that brings it to life.  The energy, the sheer joy
>> of music-making, on full display.

> I would join you in disagreeing with your friend; Bruckner symphonies are not all alike. There's the seventh, and there's everything
> else. OK, maybe the seventh and the eighth, and everything else. OK, I'm being facetious.
>
> As far as your program goes, here's one way to identify the bug and assess its potential impact: Upload the code and some test data,
> and let some of us nerds (a few of us are retired with too much time on hands) try to reproduce the crash in our own environments
> (mine is Fedora with gfortran) and hopefully figure out what's going on. If it's a hobby project, you might not need a formal NDA,
> but you could still ask for common courtesy and discretion and so on. You could share the upload link with everyone or with
> individuals.

There are calls to specific Windows APIs, so it would take considerable
modification to run on Fedora. Also, there is at least one subroutine
that uses a self-modified version of a Numerical Recipes code, which is
protected by copyright, at least the parts that I didn't modify. So I
doubt I'll go your suggested route anytime soon.

> As far as Microsoft and their DO-loop bug, I'm tempted to be appalled, but there are a couple of things to consider:
>
> How long was the interval between your bug report and the next release?

Long enough.

> If the release had passed the code-freeze point and the bug
> wasn't a regression caused by something new in the release, I could understand why they wouldn't want to delay the release until the
> bug could be fixed and the fix could be verified. The new release could have fixed a number of other bugs, and it might have done
> more than just add new features.
>
> Was the bug fixed eventually?

Not to my recollection.

> I can't imagine letting something like that stay broken past the next maintenance release.

Ah, but Microsoft eventually decided to get out of the Fortran compiler business.
It's been a VERY long time, but if memory serves, it was Microsoft Fortran Powerstation
version 4.0 that was widely advertised to be "GSA Certified to be Correct and Complete",
but certainly wasn't correct about its handling of DO loops. If I dig through old
archives of floppy discs, I might refresh my memory as to how far it got before Microsoft
dropped the product in favor of DEC's compiler. Maybe version 5.1? It might have been
through versions 4.0, 4.1, 5.0, and 5.1, but that was a LONG time ago and memories are
fuzzy.

> At my last job, I worked on embedded code that ran inside laser printers. The tolerance for bugs was zero.
>
> I also listened to Mahler symphonies late at night.

My Mahler collection is larger than my Bruckner collection, well over a dozen sets,
including multiple two-disc releases.

On 8/30/2022 6:45 PM, Dave Tholen wrote:
> <snip>
>> As far as your program goes, here's one way to identify the bug and
>> assess its potential impact: Upload the code and some test data, and
>> let some of us nerds (a few of us are retired with too much time on
>> hands) try to reproduce the crash in our own environments (mine is
>> Fedora with gfortran) and hopefully figure out what's going on. If
>> it's a hobby project, you might not need a formal NDA, but you could
>> still ask for common courtesy and discretion and so on. You could
>> share the upload link with everyone or with individuals.
>
> There are calls to specific Windows APIs, so it would take considerable
> modification to run on Fedora.  Also, there is at least one subroutine
> that uses a self-modified version of a Numerical Recipes code, which is
> protected by copyright, at least the parts that I didn't modify. So I
> doubt I'll go your suggested route anytime soon.

You could upload whatever source code you can legally share, as long as
that includes an annotated copy of the routine where the problem
appears. There's a diminished chance that anyone will be able to help
you without being able to build and run the full application, but you
never know.

>
> <snip>
>> I also listened to Mahler symphonies late at night.
>
> My Mahler collection is larger than my Bruckner collection, well over
> a dozen sets,
> including multiple two-disc releases.

After listening to classical music (in the broad sense of the term) in
the initial stages of nocturnal debugging, I would often switch to
Celtic folk rock to help me stay awake. I've always enjoyed it. Your
mileage may vary.

Louis