Thank you for the reply. I guess I will have to do a big search through
the GSIM code and find out where such a thing may happen. However, I think
this case is a bit special since I *KNOW* that the corruption occurs EVERY
event, and must be in the call to fwbos (or I also tried putBOS in the
mean time.) This is to say, before this call the SC bank is ok, after the
call it is corrupted.
Also, this is not a new bank ! I am writing the SC bank. Neither bankfmt
or txt2bos work it seems.
I will be investigating this more. It may mean that the updated GSIM won't
become available for another 2 weeks, since I will not be working on this
next week.
Thank you very much for your help. It sounds like you have gone through
plenty of hours trying to debug BOS trouble yourself. I sympathise.
Best Regards,
Maurik
> did you define the format of your new bank in the
> bankfmt calls or in the ddl file you used for txt2bos?
> If you are writing a file BOS needs to know the format of
> the bank.
>
> A corrupted bos common comes from either
>
> A) somebody is making a bank but declares the bank to be
> the wrong size (too small) ex:
> so somebody makes a bank and declares it to have
> two columns but they fill the bank as if it has
> three and walk off the bank overwriting a header of
> another bank or some vital piece of BOS bookkeeping
> information - then 3000 events later you get a core
> dump and you sit in your office for 12 hours trying
> to figure out what piece of code did this to you...
>
> B) somebody tries to write to the iw array without making
> a bank ex: somebody tries to overwrite an existing
> and doesn't get the size just right...(people should
> never even think about writing to the bcs or wcs commons
> without making a new bank...)
>
> C) some package decides it wants to clean up the bos array
> even though pointers to the iw array are still being
> used elsewhere....(not technically a corruption but
> it might as well be)
>
> I am sure there are other ways of doing it....
>
> - Joe
>