You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by Tilman Hausherr <TH...@t-online.de> on 2021/02/25 19:26:26 UTC

test failures

Something is weird with the trunk build. It fails on my PC and on 
Jenkins despite no changes.

An example is PDFontTest.testPDFox5048(). That one fails as it is, but 
doesn't fail when using a local file.

Also, the URL

https://issues.apache.org/jira/secure/attachment/13017227/stringwidth.pdf

has a FontFile3 = null when loaded with CTRL-U in PDFDebugger, but not 
when loaded locally.

Same test works fine when done in the 2.0 build

Tilman


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org


Re: test failures

Posted by Andreas Lehmkuehler <an...@lehmi.de>.
Tilman is right. I reread the javadoc and my first intention was correct. "0" is 
never returned. However, I've simplified the code.

Thanks for your input!

Andreas

Am 27.02.21 um 04:43 schrieb Tilman Hausherr:
> Am 26.02.2021 um 15:26 schrieb Jason Pyeron:
>> input.read(eofCheck) == 0 is not an EOF!
> 
> How would this ever happen that the result of that specific call is 0? eofCheck 
> is one bytes long and the javadoc says "This method blocks until input data is 
> available, end of file is detected, or an exception is thrown." and "at least 
> one byte is read".
> 
> Tilman
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org


Re: test failures

Posted by Tilman Hausherr <TH...@t-online.de>.
Am 26.02.2021 um 15:26 schrieb Jason Pyeron:
> input.read(eofCheck) == 0 is not an EOF!

How would this ever happen that the result of that specific call is 0? 
eofCheck is one bytes long and the javadoc says "This method blocks 
until input data is available, end of file is detected, or an exception 
is thrown." and "at least one byte is read".

Tilman


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org


Re: test failures

Posted by Andreas Lehmkuehler <an...@lehmi.de>.
Hi,

@Jason
Thanks for the pointer, I'm going to fix that

Andreas


Am 26.02.21 um 15:26 schrieb Jason Pyeron:
> Ow. That patch also can have issues.
> 
> 
> 101	    public RandomAccessReadBuffer(InputStream input) throws IOException
> 102	    {
> 103	        this();
> 104	        int bytesRead = 0;
> 105	        int remainingBytes = chunkSize;
> 106	        int offset = 0;
> 107	        byte[] eofCheck = new byte[1];
> 108	        while (true)
> 109	        {
> 110	            while (remainingBytes > 0
> 111	                    && (bytesRead = input.read(currentBuffer.array(), offset, remainingBytes)) > -1)
> 112	            {
> 113	                remainingBytes -= bytesRead;
> 114	                offset += bytesRead;
> 115	            }
> 116	            size += offset;
> 117	            if (remainingBytes == 0 && input.read(eofCheck) > 0)
> 118	            {
> 119	                expandBuffer();
> 120	                currentBuffer.put(eofCheck);
> 121	                offset = 1;
> 122	                remainingBytes = chunkSize - 1;
> 123	            }
> 124	            else
> 125	            {
> 126	                currentBuffer.limit(offset);
> 127	                break;
> 128	            }
> 129	        }
> 130	        seek(0);
> 131	    }
> 
> input.read(eofCheck) == 0 is not an EOF!
> 
> 
> Your loop should be something like:
> 
> 
> int bytesRead;
> 
> try
> {
> 
> while ( (bytesRead=read(buf,ofs,len)) != -1 )
> {
>    if (bytesRead == 0)
>    {
>      // do wait...
>    }
>    else
>    {
>     //analyze buffer management and make corrections
>     //copy bytes
>     //update buf, ofs, & len
>    }
> }
> 
> }
> catch (...) / finally
> {
>   //clean up
> }
> 
>> -----Original Message-----
>> From: Jason Pyeron <jp...@pdinc.us>
>> Sent: Friday, February 26, 2021 9:06 AM
>> To: dev@pdfbox.apache.org
>> Subject: RE: test failures
>>
>> Available returns an estimate of the number of bytes that can be read. It is free to say zero.
>> Typically this would be a trigger for a sleep.
>>
>> When we get a 0 followed by a 0, we read anyways.
>>
>> It is also worth noting the Javadocs give caution with regards to buffer allocation based on its
>> value.
>>
>>> -----Original Message-----
>>> From: Andreas Lehmkuehler <an...@lehmi.de>
>>> Sent: Friday, February 26, 2021 2:28 AM
>>> To: dev@pdfbox.apache.org
>>> Subject: Re: test failures
>>>
>>> @Tilman Thanks for the pointer
>>>
>>> see https://issues.apache.org/jira/browse/PDFBOX-5111
>>>
>>> Andreas
>>>
>>> Am 26.02.21 um 08:05 schrieb Tilman Hausherr:
>>>> Am 26.02.2021 um 07:51 schrieb Andreas Lehmkuehler:
>>>>> Hi,
>>>>>
>>>>> I've the same effects here and I already suspected the refactored io-code.
>>>>>
>>>>> @Tilamn: Good to hear that you already found the culprit. Do you already have
>>>>> a fix or should I have a look as well?
>>>>
>>>>
>>>> I don't have a fix. Please have a look yourself too. I'm still kindof surprised
>>>> that this would happen overnight despite no code change. Maybe some change on
>>>> apache's own server. And the javadoc of available() reads like it's more about
>>>> astrology.
>>>>
>>>> Tilman
>>>>
>>>>
>>>>>
>>>>> Andreas
>>>>>
>>>>> Am 26.02.21 um 07:30 schrieb Tilman Hausherr:
>>>>>> It happens in RandomAccessReadBuffer(InputStream input) .
>>>>>>
>>>>>> input.available() returns 0 despite that more bytes are available. This can
>>>>>> be shown with this change:
>>>>>>
>>>>>>
>>>>>>               if (remainingBytes == 0 && input.available() > 0)
>>>>>>               {
>>>>>>                   expandBuffer();
>>>>>>               }
>>>>>>               else
>>>>>>               {
>>>>>> ////////////////////// new
>>>>>>                   int by = input.read();
>>>>>>                   if (by != -1)
>>>>>>                   {
>>>>>>                       throw new IOException("hey there was more");
>>>>>>                   }
>>>>>> ///////////////////// end of new code
>>>>>> currentBuffer.limit(offset);
>>>>>>                   break;
>>>>>>               }
>>>>>>
>>>>>> also, this test code
>>>>>>
>>>>>>       @Test
>>>>>>       void testBlah() throws IOException
>>>>>>       {
>>>>>>           System.out.println("start");
>>>>>>           try (InputStream is = new
>>>>>> URL("https://issues.apache.org/jira/secure/attachment/13017227/stringwidth.pdf").openStream())
>>>>>>
>>>>>>           {
>>>>>>               RandomAccessReadBuffer rarb = new RandomAccessReadBuffer(is);
>>>>>>               System.out.println(rarb.length());
>>>>>>           }
>>>>>>       }
>>>>>>
>>>>>> shows 8192 bytes. The real size of the file is 34KB.
>>>>>>
>>>>>>
>>>>>> Tilman
>>>>>>
>>>>>> Am 25.02.2021 um 20:26 schrieb Tilman Hausherr:
>>>>>>> Something is weird with the trunk build. It fails on my PC and on Jenkins
>>>>>>> despite no changes.
>>>>>>>
>>>>>>> An example is PDFontTest.testPDFox5048(). That one fails as it is, but
>>>>>>> doesn't fail when using a local file.
>>>>>>>
>>>>>>> Also, the URL
>>>>>>>
>>>>>>> https://issues.apache.org/jira/secure/attachment/13017227/stringwidth.pdf
>>>>>>>
>>>>>>> has a FontFile3 = null when loaded with CTRL-U in PDFDebugger, but not when
>>>>>>> loaded locally.
>>>>>>>
>>>>>>> Same test works fine when done in the 2.0 build
>>>>>>>
>>>>>>> Tilman
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>>>>>>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>>>>>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>>>>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>>>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org


RE: test failures

Posted by Jason Pyeron <jp...@pdinc.us>.
Ow. That patch also can have issues.


101	    public RandomAccessReadBuffer(InputStream input) throws IOException
102	    {
103	        this();
104	        int bytesRead = 0;
105	        int remainingBytes = chunkSize;
106	        int offset = 0;
107	        byte[] eofCheck = new byte[1];
108	        while (true)
109	        {
110	            while (remainingBytes > 0
111	                    && (bytesRead = input.read(currentBuffer.array(), offset, remainingBytes)) > -1)
112	            {
113	                remainingBytes -= bytesRead;
114	                offset += bytesRead;
115	            }
116	            size += offset;
117	            if (remainingBytes == 0 && input.read(eofCheck) > 0)
118	            {
119	                expandBuffer();
120	                currentBuffer.put(eofCheck);
121	                offset = 1;
122	                remainingBytes = chunkSize - 1;
123	            }
124	            else
125	            {
126	                currentBuffer.limit(offset);
127	                break;
128	            }
129	        }
130	        seek(0);
131	    }

input.read(eofCheck) == 0 is not an EOF!


Your loop should be something like:


int bytesRead;

try
{

while ( (bytesRead=read(buf,ofs,len)) != -1 )
{
  if (bytesRead == 0)
  {
    // do wait...
  }
  else
  {
   //analyze buffer management and make corrections
   //copy bytes
   //update buf, ofs, & len
  }
}

}
catch (...) / finally 
{
 //clean up
}

> -----Original Message-----
> From: Jason Pyeron <jp...@pdinc.us>
> Sent: Friday, February 26, 2021 9:06 AM
> To: dev@pdfbox.apache.org
> Subject: RE: test failures
> 
> Available returns an estimate of the number of bytes that can be read. It is free to say zero.
> Typically this would be a trigger for a sleep.
> 
> When we get a 0 followed by a 0, we read anyways.
> 
> It is also worth noting the Javadocs give caution with regards to buffer allocation based on its
> value.
> 
> > -----Original Message-----
> > From: Andreas Lehmkuehler <an...@lehmi.de>
> > Sent: Friday, February 26, 2021 2:28 AM
> > To: dev@pdfbox.apache.org
> > Subject: Re: test failures
> >
> > @Tilman Thanks for the pointer
> >
> > see https://issues.apache.org/jira/browse/PDFBOX-5111
> >
> > Andreas
> >
> > Am 26.02.21 um 08:05 schrieb Tilman Hausherr:
> > > Am 26.02.2021 um 07:51 schrieb Andreas Lehmkuehler:
> > >> Hi,
> > >>
> > >> I've the same effects here and I already suspected the refactored io-code.
> > >>
> > >> @Tilamn: Good to hear that you already found the culprit. Do you already have
> > >> a fix or should I have a look as well?
> > >
> > >
> > > I don't have a fix. Please have a look yourself too. I'm still kindof surprised
> > > that this would happen overnight despite no code change. Maybe some change on
> > > apache's own server. And the javadoc of available() reads like it's more about
> > > astrology.
> > >
> > > Tilman
> > >
> > >
> > >>
> > >> Andreas
> > >>
> > >> Am 26.02.21 um 07:30 schrieb Tilman Hausherr:
> > >>> It happens in RandomAccessReadBuffer(InputStream input) .
> > >>>
> > >>> input.available() returns 0 despite that more bytes are available. This can
> > >>> be shown with this change:
> > >>>
> > >>>
> > >>>              if (remainingBytes == 0 && input.available() > 0)
> > >>>              {
> > >>>                  expandBuffer();
> > >>>              }
> > >>>              else
> > >>>              {
> > >>> ////////////////////// new
> > >>>                  int by = input.read();
> > >>>                  if (by != -1)
> > >>>                  {
> > >>>                      throw new IOException("hey there was more");
> > >>>                  }
> > >>> ///////////////////// end of new code
> > >>> currentBuffer.limit(offset);
> > >>>                  break;
> > >>>              }
> > >>>
> > >>> also, this test code
> > >>>
> > >>>      @Test
> > >>>      void testBlah() throws IOException
> > >>>      {
> > >>>          System.out.println("start");
> > >>>          try (InputStream is = new
> > >>> URL("https://issues.apache.org/jira/secure/attachment/13017227/stringwidth.pdf").openStream())
> > >>>
> > >>>          {
> > >>>              RandomAccessReadBuffer rarb = new RandomAccessReadBuffer(is);
> > >>>              System.out.println(rarb.length());
> > >>>          }
> > >>>      }
> > >>>
> > >>> shows 8192 bytes. The real size of the file is 34KB.
> > >>>
> > >>>
> > >>> Tilman
> > >>>
> > >>> Am 25.02.2021 um 20:26 schrieb Tilman Hausherr:
> > >>>> Something is weird with the trunk build. It fails on my PC and on Jenkins
> > >>>> despite no changes.
> > >>>>
> > >>>> An example is PDFontTest.testPDFox5048(). That one fails as it is, but
> > >>>> doesn't fail when using a local file.
> > >>>>
> > >>>> Also, the URL
> > >>>>
> > >>>> https://issues.apache.org/jira/secure/attachment/13017227/stringwidth.pdf
> > >>>>
> > >>>> has a FontFile3 = null when loaded with CTRL-U in PDFDebugger, but not when
> > >>>> loaded locally.
> > >>>>
> > >>>> Same test works fine when done in the 2.0 build
> > >>>>
> > >>>> Tilman
> > >>>>
> > >>>>
> > >>>> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> > >>>> For additional commands, e-mail: dev-help@pdfbox.apache.org
> > >>>>
> > >>>
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> > >>> For additional commands, e-mail: dev-help@pdfbox.apache.org
> > >>>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> > >> For additional commands, e-mail: dev-help@pdfbox.apache.org
> > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> > > For additional commands, e-mail: dev-help@pdfbox.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> > For additional commands, e-mail: dev-help@pdfbox.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org


RE: test failures

Posted by Jason Pyeron <jp...@pdinc.us>.
Available returns an estimate of the number of bytes that can be read. It is free to say zero. Typically this would be a trigger for a sleep.

When we get a 0 followed by a 0, we read anyways.

It is also worth noting the Javadocs give caution with regards to buffer allocation based on its value.

> -----Original Message-----
> From: Andreas Lehmkuehler <an...@lehmi.de>
> Sent: Friday, February 26, 2021 2:28 AM
> To: dev@pdfbox.apache.org
> Subject: Re: test failures
> 
> @Tilman Thanks for the pointer
> 
> see https://issues.apache.org/jira/browse/PDFBOX-5111
> 
> Andreas
> 
> Am 26.02.21 um 08:05 schrieb Tilman Hausherr:
> > Am 26.02.2021 um 07:51 schrieb Andreas Lehmkuehler:
> >> Hi,
> >>
> >> I've the same effects here and I already suspected the refactored io-code.
> >>
> >> @Tilamn: Good to hear that you already found the culprit. Do you already have
> >> a fix or should I have a look as well?
> >
> >
> > I don't have a fix. Please have a look yourself too. I'm still kindof surprised
> > that this would happen overnight despite no code change. Maybe some change on
> > apache's own server. And the javadoc of available() reads like it's more about
> > astrology.
> >
> > Tilman
> >
> >
> >>
> >> Andreas
> >>
> >> Am 26.02.21 um 07:30 schrieb Tilman Hausherr:
> >>> It happens in RandomAccessReadBuffer(InputStream input) .
> >>>
> >>> input.available() returns 0 despite that more bytes are available. This can
> >>> be shown with this change:
> >>>
> >>>
> >>>              if (remainingBytes == 0 && input.available() > 0)
> >>>              {
> >>>                  expandBuffer();
> >>>              }
> >>>              else
> >>>              {
> >>> ////////////////////// new
> >>>                  int by = input.read();
> >>>                  if (by != -1)
> >>>                  {
> >>>                      throw new IOException("hey there was more");
> >>>                  }
> >>> ///////////////////// end of new code
> >>> currentBuffer.limit(offset);
> >>>                  break;
> >>>              }
> >>>
> >>> also, this test code
> >>>
> >>>      @Test
> >>>      void testBlah() throws IOException
> >>>      {
> >>>          System.out.println("start");
> >>>          try (InputStream is = new
> >>> URL("https://issues.apache.org/jira/secure/attachment/13017227/stringwidth.pdf").openStream())
> >>>
> >>>          {
> >>>              RandomAccessReadBuffer rarb = new RandomAccessReadBuffer(is);
> >>>              System.out.println(rarb.length());
> >>>          }
> >>>      }
> >>>
> >>> shows 8192 bytes. The real size of the file is 34KB.
> >>>
> >>>
> >>> Tilman
> >>>
> >>> Am 25.02.2021 um 20:26 schrieb Tilman Hausherr:
> >>>> Something is weird with the trunk build. It fails on my PC and on Jenkins
> >>>> despite no changes.
> >>>>
> >>>> An example is PDFontTest.testPDFox5048(). That one fails as it is, but
> >>>> doesn't fail when using a local file.
> >>>>
> >>>> Also, the URL
> >>>>
> >>>> https://issues.apache.org/jira/secure/attachment/13017227/stringwidth.pdf
> >>>>
> >>>> has a FontFile3 = null when loaded with CTRL-U in PDFDebugger, but not when
> >>>> loaded locally.
> >>>>
> >>>> Same test works fine when done in the 2.0 build
> >>>>
> >>>> Tilman
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> >>>> For additional commands, e-mail: dev-help@pdfbox.apache.org
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> >>> For additional commands, e-mail: dev-help@pdfbox.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> >> For additional commands, e-mail: dev-help@pdfbox.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> > For additional commands, e-mail: dev-help@pdfbox.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org


Re: test failures

Posted by Andreas Lehmkuehler <an...@lehmi.de>.
@Tilman Thanks for the pointer

see https://issues.apache.org/jira/browse/PDFBOX-5111

Andreas

Am 26.02.21 um 08:05 schrieb Tilman Hausherr:
> Am 26.02.2021 um 07:51 schrieb Andreas Lehmkuehler:
>> Hi,
>>
>> I've the same effects here and I already suspected the refactored io-code.
>>
>> @Tilamn: Good to hear that you already found the culprit. Do you already have 
>> a fix or should I have a look as well?
> 
> 
> I don't have a fix. Please have a look yourself too. I'm still kindof surprised 
> that this would happen overnight despite no code change. Maybe some change on 
> apache's own server. And the javadoc of available() reads like it's more about 
> astrology.
> 
> Tilman
> 
> 
>>
>> Andreas
>>
>> Am 26.02.21 um 07:30 schrieb Tilman Hausherr:
>>> It happens in RandomAccessReadBuffer(InputStream input) .
>>>
>>> input.available() returns 0 despite that more bytes are available. This can 
>>> be shown with this change:
>>>
>>>
>>>              if (remainingBytes == 0 && input.available() > 0)
>>>              {
>>>                  expandBuffer();
>>>              }
>>>              else
>>>              {
>>> ////////////////////// new
>>>                  int by = input.read();
>>>                  if (by != -1)
>>>                  {
>>>                      throw new IOException("hey there was more");
>>>                  }
>>> ///////////////////// end of new code
>>> currentBuffer.limit(offset);
>>>                  break;
>>>              }
>>>
>>> also, this test code
>>>
>>>      @Test
>>>      void testBlah() throws IOException
>>>      {
>>>          System.out.println("start");
>>>          try (InputStream is = new 
>>> URL("https://issues.apache.org/jira/secure/attachment/13017227/stringwidth.pdf").openStream()) 
>>>
>>>          {
>>>              RandomAccessReadBuffer rarb = new RandomAccessReadBuffer(is);
>>>              System.out.println(rarb.length());
>>>          }
>>>      }
>>>
>>> shows 8192 bytes. The real size of the file is 34KB.
>>>
>>>
>>> Tilman
>>>
>>> Am 25.02.2021 um 20:26 schrieb Tilman Hausherr:
>>>> Something is weird with the trunk build. It fails on my PC and on Jenkins 
>>>> despite no changes.
>>>>
>>>> An example is PDFontTest.testPDFox5048(). That one fails as it is, but 
>>>> doesn't fail when using a local file.
>>>>
>>>> Also, the URL
>>>>
>>>> https://issues.apache.org/jira/secure/attachment/13017227/stringwidth.pdf
>>>>
>>>> has a FontFile3 = null when loaded with CTRL-U in PDFDebugger, but not when 
>>>> loaded locally.
>>>>
>>>> Same test works fine when done in the 2.0 build
>>>>
>>>> Tilman
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>>>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org


Re: test failures

Posted by Tilman Hausherr <TH...@t-online.de>.
Am 26.02.2021 um 07:51 schrieb Andreas Lehmkuehler:
> Hi,
>
> I've the same effects here and I already suspected the refactored 
> io-code.
>
> @Tilamn: Good to hear that you already found the culprit. Do you 
> already have a fix or should I have a look as well?


I don't have a fix. Please have a look yourself too. I'm still kindof 
surprised that this would happen overnight despite no code change. Maybe 
some change on apache's own server. And the javadoc of available() reads 
like it's more about astrology.

Tilman


>
> Andreas
>
> Am 26.02.21 um 07:30 schrieb Tilman Hausherr:
>> It happens in RandomAccessReadBuffer(InputStream input) .
>>
>> input.available() returns 0 despite that more bytes are available. 
>> This can be shown with this change:
>>
>>
>>              if (remainingBytes == 0 && input.available() > 0)
>>              {
>>                  expandBuffer();
>>              }
>>              else
>>              {
>> ////////////////////// new
>>                  int by = input.read();
>>                  if (by != -1)
>>                  {
>>                      throw new IOException("hey there was more");
>>                  }
>> ///////////////////// end of new code
>> currentBuffer.limit(offset);
>>                  break;
>>              }
>>
>> also, this test code
>>
>>      @Test
>>      void testBlah() throws IOException
>>      {
>>          System.out.println("start");
>>          try (InputStream is = new 
>> URL("https://issues.apache.org/jira/secure/attachment/13017227/stringwidth.pdf").openStream()) 
>>
>>          {
>>              RandomAccessReadBuffer rarb = new 
>> RandomAccessReadBuffer(is);
>>              System.out.println(rarb.length());
>>          }
>>      }
>>
>> shows 8192 bytes. The real size of the file is 34KB.
>>
>>
>> Tilman
>>
>> Am 25.02.2021 um 20:26 schrieb Tilman Hausherr:
>>> Something is weird with the trunk build. It fails on my PC and on 
>>> Jenkins despite no changes.
>>>
>>> An example is PDFontTest.testPDFox5048(). That one fails as it is, 
>>> but doesn't fail when using a local file.
>>>
>>> Also, the URL
>>>
>>> https://issues.apache.org/jira/secure/attachment/13017227/stringwidth.pdf 
>>>
>>>
>>> has a FontFile3 = null when loaded with CTRL-U in PDFDebugger, but 
>>> not when loaded locally.
>>>
>>> Same test works fine when done in the 2.0 build
>>>
>>> Tilman
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org


Re: test failures

Posted by Andreas Lehmkuehler <an...@lehmi.de>.
Hi,

I've the same effects here and I already suspected the refactored io-code.

@Tilamn: Good to hear that you already found the culprit. Do you already have a 
fix or should I have a look as well?

Andreas

Am 26.02.21 um 07:30 schrieb Tilman Hausherr:
> It happens in RandomAccessReadBuffer(InputStream input) .
> 
> input.available() returns 0 despite that more bytes are available. This can be 
> shown with this change:
> 
> 
>              if (remainingBytes == 0 && input.available() > 0)
>              {
>                  expandBuffer();
>              }
>              else
>              {
> ////////////////////// new
>                  int by = input.read();
>                  if (by != -1)
>                  {
>                      throw new IOException("hey there was more");
>                  }
> ///////////////////// end of new code
> currentBuffer.limit(offset);
>                  break;
>              }
> 
> also, this test code
> 
>      @Test
>      void testBlah() throws IOException
>      {
>          System.out.println("start");
>          try (InputStream is = new 
> URL("https://issues.apache.org/jira/secure/attachment/13017227/stringwidth.pdf").openStream()) 
> 
>          {
>              RandomAccessReadBuffer rarb = new RandomAccessReadBuffer(is);
>              System.out.println(rarb.length());
>          }
>      }
> 
> shows 8192 bytes. The real size of the file is 34KB.
> 
> 
> Tilman
> 
> Am 25.02.2021 um 20:26 schrieb Tilman Hausherr:
>> Something is weird with the trunk build. It fails on my PC and on Jenkins 
>> despite no changes.
>>
>> An example is PDFontTest.testPDFox5048(). That one fails as it is, but doesn't 
>> fail when using a local file.
>>
>> Also, the URL
>>
>> https://issues.apache.org/jira/secure/attachment/13017227/stringwidth.pdf
>>
>> has a FontFile3 = null when loaded with CTRL-U in PDFDebugger, but not when 
>> loaded locally.
>>
>> Same test works fine when done in the 2.0 build
>>
>> Tilman
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org


Re: test failures

Posted by Tilman Hausherr <TH...@t-online.de>.
It happens in RandomAccessReadBuffer(InputStream input) .

input.available() returns 0 despite that more bytes are available. This 
can be shown with this change:


             if (remainingBytes == 0 && input.available() > 0)
             {
                 expandBuffer();
             }
             else
             {
////////////////////// new
                 int by = input.read();
                 if (by != -1)
                 {
                     throw new IOException("hey there was more");
                 }
///////////////////// end of new code
currentBuffer.limit(offset);
                 break;
             }

also, this test code

     @Test
     void testBlah() throws IOException
     {
         System.out.println("start");
         try (InputStream is = new 
URL("https://issues.apache.org/jira/secure/attachment/13017227/stringwidth.pdf").openStream())
         {
             RandomAccessReadBuffer rarb = new RandomAccessReadBuffer(is);
             System.out.println(rarb.length());
         }
     }

shows 8192 bytes. The real size of the file is 34KB.


Tilman

Am 25.02.2021 um 20:26 schrieb Tilman Hausherr:
> Something is weird with the trunk build. It fails on my PC and on 
> Jenkins despite no changes.
>
> An example is PDFontTest.testPDFox5048(). That one fails as it is, but 
> doesn't fail when using a local file.
>
> Also, the URL
>
> https://issues.apache.org/jira/secure/attachment/13017227/stringwidth.pdf
>
> has a FontFile3 = null when loaded with CTRL-U in PDFDebugger, but not 
> when loaded locally.
>
> Same test works fine when done in the 2.0 build
>
> Tilman
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org


Re: test failures

Posted by Tilman Hausherr <TH...@t-online.de>.
Am 25.02.2021 um 20:31 schrieb Jason Pyeron:
>> -----Original Message-----
>> From: Tilman Hausherr <TH...@t-online.de>
>> Sent: Thursday, February 25, 2021 2:26 PM
>> To: dev@pdfbox.apache.org
>> Subject: test failures
>>
>> Something is weird with the trunk build. It fails on my PC and on
>> Jenkins despite no changes.
>>
>> An example is PDFontTest.testPDFox5048(). That one fails as it is, but
>> doesn't fail when using a local file.
>>
>> Also, the URL
>>
>> https://issues.apache.org/jira/secure/attachment/13017227/stringwidth.pdf
>>
>> has a FontFile3 = null when loaded with CTRL-U in PDFDebugger, but not
>> when loaded locally.
>>
>> Same test works fine when done in the 2.0 build
> Would you like others to run the test?


Yeah feel free to try. Run the trunk build, there are about 15 tests 
that fail.

Tilman



>
>> Tilman
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org


RE: test failures

Posted by Jason Pyeron <jp...@pdinc.us>.
> -----Original Message-----
> From: Tilman Hausherr <TH...@t-online.de>
> Sent: Thursday, February 25, 2021 2:26 PM
> To: dev@pdfbox.apache.org
> Subject: test failures
> 
> Something is weird with the trunk build. It fails on my PC and on
> Jenkins despite no changes.
> 
> An example is PDFontTest.testPDFox5048(). That one fails as it is, but
> doesn't fail when using a local file.
> 
> Also, the URL
> 
> https://issues.apache.org/jira/secure/attachment/13017227/stringwidth.pdf
> 
> has a FontFile3 = null when loaded with CTRL-U in PDFDebugger, but not
> when loaded locally.
> 
> Same test works fine when done in the 2.0 build

Would you like others to run the test?

> 
> Tilman
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org