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 |
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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |