error uploading file

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

error uploading file

EstebanLM
Hi,
I'm again with the basicNew: primitive failed when trying to upload a file... I tried to avoid the problem by using swazoo server, but that was not an option :(
This is the problem: I need to upload files (using "streamUploads" option of comanche adaptor), and that works fine in development, but not in production.
When running in production, I'm getting a primitive failed when trying to store a byte string, because it is receiving a -19 as a requested storage size.

I'm attaching a log with the debugger information I could get.

Also, this is the system information:
CPU Intel(R) Xeon(R) CPU X3360 @ 2.83GHz
SO Linux, I can't say which version... looks like a suse, but I dunno.
Pharo 1.1.1 (core)
Seaside Loaded with ConfigurationOfSeaside30 version 3.0.2
VM Tried both: exuperi 0.15 and latest cogvm for unix





Thanks,
Esteban
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

report.log (29K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: error uploading file

Philippe Marschall
2010/12/7 Esteban Lorenzano <[hidden email]>:

> Hi,
> I'm again with the basicNew: primitive failed when trying to upload a file... I tried to avoid the problem by using swazoo server, but that was not an option :(
> This is the problem: I need to upload files (using "streamUploads" option of comanche adaptor), and that works fine in development, but not in production.
> When running in production, I'm getting a primitive failed when trying to store a byte string, because it is receiving a -19 as a requested storage size.
>
> I'm attaching a log with the debugger information I could get.
>
> Also, this is the system information:
> CPU             Intel(R) Xeon(R) CPU X3360 @ 2.83GHz
> SO                      Linux, I can't say which version... looks like a suse, but I dunno.
> Pharo           1.1.1 (core)
> Seaside         Loaded with ConfigurationOfSeaside30 version 3.0.2
> VM                      Tried both: exuperi 0.15 and latest cogvm for unix

You don't have by chance the file you tried to upload? I think the
problem is right here:

SocketStream>>nextInBuffer:
        Receiver: SocketStream[inbuf:4kb/outbuf:4kb]
        Arguments and temporary variables:
                anInteger: -19
                start: 1388
                amount: -19
        Receiver's instance variables:
                recentlyRead: 0
                socket: a Socket[connected]
                inBuffer: '3 00000 n
0000114044 00000 n
0000114067 00000 n
0000114331 00000 ...etc...
                outBuffer: '
           ...etc...
                inNextToWrite: 1411
                outNextToWrite: 1
                lastRead: 1368
                timeout: 10
                autoFlush: false
                bufferSize: 4096
                binary: false
                shouldSignal: true

SocketStream>>upToAll:bufferSize:do:
        Receiver: SocketStream[inbuf:4kb/outbuf:4kb]
        Arguments and temporary variables:
                aStringOrByteArray: '
------WebKitFormBoundaryqD0oYzAvsNrfKLUp'
                maxSize: 1000000
                aBlock: [:buffer | firstBuffer
                ifNil: [size := size + buffer size.
                        outStre...etc...
                index: 0
                sz: 42
                result: nil
                lastRecentlyRead: 0
                searchedSoFar: 23
                insz: 23
        Receiver's instance variables:
                recentlyRead: 0
                socket: a Socket[connected]
                inBuffer: '3 00000 n

Somehow #upToAll:bufferSize:do: sends #nextInBuffer: to self with an
argument of -19.

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: error uploading file

EstebanLM
yes, I'm attaching it, but it happens with any file I try to upload (in fact, the pdf I was uploading is the "Alien FFI.pdf", which I was using for testing)

Cheers,
Esteban



 
El 08/12/2010, a las 3:00a.m., Philippe Marschall escribió:

> 2010/12/7 Esteban Lorenzano <[hidden email]>:
>> Hi,
>> I'm again with the basicNew: primitive failed when trying to upload a file... I tried to avoid the problem by using swazoo server, but that was not an option :(
>> This is the problem: I need to upload files (using "streamUploads" option of comanche adaptor), and that works fine in development, but not in production.
>> When running in production, I'm getting a primitive failed when trying to store a byte string, because it is receiving a -19 as a requested storage size.
>>
>> I'm attaching a log with the debugger information I could get.
>>
>> Also, this is the system information:
>> CPU             Intel(R) Xeon(R) CPU X3360 @ 2.83GHz
>> SO                      Linux, I can't say which version... looks like a suse, but I dunno.
>> Pharo           1.1.1 (core)
>> Seaside         Loaded with ConfigurationOfSeaside30 version 3.0.2
>> VM                      Tried both: exuperi 0.15 and latest cogvm for unix
>
> You don't have by chance the file you tried to upload? I think the
> problem is right here:
>
> SocketStream>>nextInBuffer:
> Receiver: SocketStream[inbuf:4kb/outbuf:4kb]
> Arguments and temporary variables:
> anInteger: -19
> start: 1388
> amount: -19
> Receiver's instance variables:
> recentlyRead: 0
> socket: a Socket[connected]
> inBuffer: '3 00000 n
> 0000114044 00000 n
> 0000114067 00000 n
> 0000114331 00000 ...etc...
> outBuffer: '
>           ...etc...
> inNextToWrite: 1411
> outNextToWrite: 1
> lastRead: 1368
> timeout: 10
> autoFlush: false
> bufferSize: 4096
> binary: false
> shouldSignal: true
>
> SocketStream>>upToAll:bufferSize:do:
> Receiver: SocketStream[inbuf:4kb/outbuf:4kb]
> Arguments and temporary variables:
> aStringOrByteArray: '
> ------WebKitFormBoundaryqD0oYzAvsNrfKLUp'
> maxSize: 1000000
> aBlock: [:buffer | firstBuffer
> ifNil: [size := size + buffer size.
> outStre...etc...
> index: 0
> sz: 42
> result: nil
> lastRecentlyRead: 0
> searchedSoFar: 23
> insz: 23
> Receiver's instance variables:
> recentlyRead: 0
> socket: a Socket[connected]
> inBuffer: '3 00000 n
>
> Somehow #upToAll:bufferSize:do: sends #nextInBuffer: to self with an
> argument of -19.
>
> Cheers
> Philippe
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Alien FFI.2.pdf (216K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: error uploading file

Bob Arning
In reply to this post by Philippe Marschall

On 12/8/10 1:00 AM, Philippe Marschall wrote:
> Somehow #upToAll:bufferSize:do: sends #nextInBuffer: to self with an
> argument of -19.
This method does not seem happy when the buffer contents are shorter
than the search string. If you change...

     index = 0 ifTrue: [
         aBlock value: (self nextInBuffer: (searchedSoFar - sz)) ].
     ].

to...

     (index = 0 and: [searchedSoFar > sz]) ifTrue: [
         aBlock value: (self nextInBuffer: (searchedSoFar - sz)) ].
     ].

it might be happier.

It's also interesting that...

         searchedSoFar:     23
         insz:     23

when this...

         inNextToWrite:     1411
         outNextToWrite:     1
         lastRead:     1368

would argue for 42 rather than 23. Makes me wonder if something caused
socket stream to read the rest of the data *after* the error occurred.

Cheers,
Bob
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: error uploading file

EstebanLM
Hi,
ok, I tried that, and adding that to streamUploads: *seems* to be working now :)

thanks a lot!

Esteban

El 08/12/2010, a las 10:13a.m., Bob Arning escribió:

>
> On 12/8/10 1:00 AM, Philippe Marschall wrote:
>> Somehow #upToAll:bufferSize:do: sends #nextInBuffer: to self with an
>> argument of -19.
> This method does not seem happy when the buffer contents are shorter than the search string. If you change...
>
>    index = 0 ifTrue: [
>        aBlock value: (self nextInBuffer: (searchedSoFar - sz)) ].
>    ].
>
> to...
>
>    (index = 0 and: [searchedSoFar > sz]) ifTrue: [
>        aBlock value: (self nextInBuffer: (searchedSoFar - sz)) ].
>    ].
>
> it might be happier.
>
> It's also interesting that...
>
>        searchedSoFar:     23
>        insz:     23
>
> when this...
>
>        inNextToWrite:     1411
>        outNextToWrite:     1
>        lastRead:     1368
>
> would argue for 42 rather than 23. Makes me wonder if something caused socket stream to read the rest of the data *after* the error occurred.
>
> Cheers,
> Bob
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: error uploading file

Philippe Marschall
In reply to this post by Bob Arning
2010/12/8 Bob Arning <[hidden email]>:

>
> On 12/8/10 1:00 AM, Philippe Marschall wrote:
>>
>> Somehow #upToAll:bufferSize:do: sends #nextInBuffer: to self with an
>> argument of -19.
>
> This method does not seem happy when the buffer contents are shorter than
> the search string. If you change...
>
>    index = 0 ifTrue: [
>        aBlock value: (self nextInBuffer: (searchedSoFar - sz)) ].
>    ].
>
> to...
>
>    (index = 0 and: [searchedSoFar > sz]) ifTrue: [
>        aBlock value: (self nextInBuffer: (searchedSoFar - sz)) ].
>    ].
>
> it might be happier.
>
> It's also interesting that...
>
>        searchedSoFar:     23
>        insz:     23
>
> when this...
>
>        inNextToWrite:     1411
>        outNextToWrite:     1
>        lastRead:     1368
>
> would argue for 42 rather than 23. Makes me wonder if something caused
> socket stream to read the rest of the data *after* the error occurred.

Good catch, thanks a lot.
http://code.google.com/p/seaside/issues/detail?id=621

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside