Strange AllocVec Problem

@MigthyMax

if it is a hexdump of a struct I think something has happened when
you are copying/transfering the struct... I do hope you know that
everything coming over network does not need to be swapped, you
are safe in that respect on the amiga... the same goes for
sending data on the network, you should not do anything with it
before sending the data.

@trgswe

Good to know that i don't need to swap the data. That was a little question in back mind, which got answered now.
Will see that i rewrite the network read/write stuff.

@jabirulo

Whenever you make your next test run. If you can give the debug output and maybe even the a wireshark capturing would be nice.

@MigthyMax

ok, noted. will use wireshark next time I test.

I captured the last debug ouptut. here it is:
smb2_output

I'm starting to really giving up on this. I've rewritten a lot of my code to clean it up and so on.
Now it just crashes without any hint what the cause could be. Now it even doesn't relate anymore to an nearby AllocVec call.
If I run my current program with debuglevel=20 the crash output looks like this:



It looks like the crash is in parallel to the executing of my program and that workbench crashed, and thus my program continues to tun? But interaction is not possible because of the crashed workbench.

Obviously it must be something in my program, which causes the crash. But currently I'm out of ideas.

Anyone any idea how to further track down the cause?

Here is the current executable and the source.

@MigthyMax

Hi, not sure but as it seems the crash happens just here:

int readyDescriptors = ISocket->WaitSelect( socket +1,&readFds,&writeFds,&exceptFds,NULL,&signals );

have you checked that args you pass are valid/ok?

Just a silly cooment

@MigthyMax

Network programmering is really hard. on amigaos due to the way sockets work, sockets is not shared between threads/processes. Clib2 /newlib is also hiding the Amiga api, and gets in the way.

As for memory corruption, you need slow your program down, you can allocate som large memory blocks, you can just inspect for changes, crc checks. Or try to complete the same code on windows or Linux, bugs often show up other systems with better memory protection.

@all

now i have the crash reproducible. And it crashes during a call to AllocVecTags.

Here the binary version, which crashes and the sources

The line which case the crash is in the file smb2_tree_connect.c in line 105:



if i modified the source to this, which works as long you try to connect to an invalid share name:



If you use a valid share name it can crash because of other circumstances.

Anyway i don't understand why/what on earth the call crashes. I even changed the memory type to MEMF_SHARED from MEMF-PRIVATE, maybe the bsdsocket library requires that?

@all

During writing my own post, i thought i switch AllocVecTag to calloc. And that seems to work. Why?

@MigthyMax

I think size variable might be 0, try replace with sizeof(struct SMB_Tree_Connect_Response), maybe calloc allocs extra bytes.

Also consider using “new” and “delete”, instead of calloc/malloc/free, and , AllocVec/FreeVec,
source code often becomes more readable using classes, and it more likely your code will have less bugs.

@MigthyMax

as LiveForIt posted, change to:

struct SMB_Tree_Connect_Response *message = (struct SMB_Tree_Connect_Response *)IExec->AllocVecTags(
//    size,
sizeof(struct SMB_Tree_Connect_Response),
    AVT_Type,        MEMF_SHARED,
    AVT_ClearWithValue,    0,
    TAG_DONE );

and see what happens.