Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

error uploading file #621

Closed
GoogleCodeExporter opened this issue Mar 25, 2015 · 2 comments
Closed

error uploading file #621

GoogleCodeExporter opened this issue Mar 25, 2015 · 2 comments
Labels
auto-migrated Kom Priority-Medium Type-Defect

Comments

@GoogleCodeExporter
Copy link 

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

Original issue reported on code.google.com by philippe...@gmail.com on 10 Dec 2010 at 6:08

Attachments:
@GoogleCodeExporter
Copy link
Author 

On 12/8/10 2:13 PM, Bob Arning 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

Original comment by philippe...@gmail.com on 10 Dec 2010 at 6:10

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author 

Name: KomHttpServerLight-pmm.6
Author: pmm
Time: 10 December 2010, 7:14:49 am
UUID: 3a0d767c-d439-4dd4-8733-5c9a9718437e
Ancestors: KomHttpServerLight-lr.5

- Issue 621:    error uploading file
- http://code.google.com/p/seaside/issues/detail?id=621

Name: KomHttpServer-pmm.63
Author: pmm
Time: 10 December 2010, 7:18:56 am
UUID: 414cc3d2-34cd-40d8-83e7-ac69b736e309
Ancestors: KomHttpServer-lr.62

- Issue 621:    error uploading file
- http://code.google.com/p/seaside/issues/detail?id=621

Original comment by philippe...@gmail.com on 10 Dec 2010 at 6:19

  • Changed state: Fixed
  • Added labels: ****
  • Removed labels: ****

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
auto-migrated Kom Priority-Medium Type-Defect
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@GoogleCodeExporter