2009/7/1 Mark Taylor <[log in to unmask]>:
> On Wed, 1 Jul 2009, David Berry wrote:
>
>> > not sure, but my problem is more pervasive than just calling astWrite -
>> > almost anything done to a FitsChan seems to give a core dump, though
>> > other classes seem to work as before. My current best guess is that
>> > this has to do with some JNI-specific tricks that I'm playing, so
>> > I'm trying to patch it up, but it used to work OK. David, anything
>> > spring to mind about changes to the way FitsChan works introduced
>> > in the last few months?
>>
>> Can you give me a date at which you believe it worked correctly - just
>> to limit how far back I go?
>
> end of February when I finished with the threading changes it was
> definitely working. I'm not desperate yet, so no need to look
> too hard for now, but if you think of a change in the internals
> which might have been significant (possibly: calling the source
> function in more places than it used to?) pass it on.
Ah well, in that case.. Look at commit
c329662903d33b329f499399527a4fdd6717f5ae,described in the fitschan.c
prologue:
* 11-JUN-2009 (DSB):
* Delay reading cards from the source until they are actually
* needed. Previously, the source function was called in the
* FitsChan initialiser, but this means it is not possible for
* application code to call astPutChannelData before the source
* function is called. The ReadFromSource function is now called
* at the start of each (nearly) public or protected function to
* ensure the source function has been called (the source function
* pointer in the FitsChan is then nullified to ensure it is not
* called again).
Maybe that last parenthesised phrase???
David
|