Verse is network protocol.
Ok I have been working a bit on a new verse release. I have added select now so the verse server wont eat your CPU for breakfast. Some other stuff is new, a large part of the seduce UI tool kit have been re-written.
Im hoping to set up a page with an invitation to contribute soon and there will be some docs and tutorials too. It will be up in a few days.
Im going to go to 3D festival in denmark next week, i will only be there for one day but if any one wants too meet up...
Cheers
E
Cant stop listening to white stripes.
verse 2.0 finaly out.
Moderators: jesterKing, stiv
Yes, there wont be much of a "side" everything will be integrated using verse.
Right now im writing some stuff to set up a developer section at blender.org for the Next Gen blender project. I hope to mail it to ton later tonight. then we will see when he has any time to put it up on the site.
Writing docs for verse is big deal, so the first version is not at all going to be complete but enough for you to start coding for it (i hope..)
Cheers
E
Right now im writing some stuff to set up a developer section at blender.org for the Next Gen blender project. I hope to mail it to ton later tonight. then we will see when he has any time to put it up on the site.
Writing docs for verse is big deal, so the first version is not at all going to be complete but enough for you to start coding for it (i hope..)
Cheers
E
-
Money_YaY!
- Posts: 442
- Joined: Wed Oct 23, 2002 2:47 pm
Hello Eskil,
I've tracked down what is causing verse to crash. The pack functions are overrunning their buffers.
For example, in vll_send_connect:
Here is what I get with v_test.c:
head = v_cmd_buf_allocate(0); // is allocating 44 bytes.
buf = ((VCMDBuffer10 *)head)->buf; // buf = head+32, which leaves 12 bytes.
Then you pack an uint8 (1 byte), an uint32 (4 bytes), and two strings (up to 16 bytes each, but only 6 bytes each in this case, "eskil" and "nixon"). That is 17 bytes, but can be up to 37. This overruns the remaining 12 bytes.
The program doesn't actually crash at this point, but does later at:
v_con_connect() -> v_fs_create_func_storage() -> connection = malloc(sizeof *connection);
I'm still trying to fully understand what causes this overrun to cause a segmentation fault two malloc calls later.
By changin the buffer allocation to v_cmd_buf_allocate(1) (which allocates 84 bytes) in this case, v_test will run without errors.
I hope this helps. I remember in reading about debugging malloc calls, there is a way to enforce strict bounds checking, but it's slow. I'll have to look that up again.
All in all, by tweaking the buffer allocations, I have connector up and running. Yay! I can connect to and dissconnect from the server, create new nodes, hide, unhide... all that fun stuff.
The zoom isn't working, so it's REALLY hard to read the text (more like impossible 
).
Keep up the awesome work!
I've tracked down what is causing verse to crash. The pack functions are overrunning their buffers.
For example, in vll_send_connect:
Code: Select all
void vll_send_connect(char *name, char *pass, void *address, VSession * *connection)
{
uint8 *buf;
uint buffer_pos = 0;
VCMDBufHead *head;
head = v_cmd_buf_allocate(0);/* Allocating the buffer */
buf = ((VCMDBuffer10 *)head)->buf;
buffer_pos += vnp_raw_pack_uint8(&buf[buffer_pos], 0);/* Packing the command */
buffer_pos += vnp_raw_pack_uint32(&buf[buffer_pos], 0);
#if defined(V_PRINT_SEND_COMMANDS)
printf("send: vll_send_connect(name = %s pass = %s address = %p connection = %p );\n", name, pass, address, connection);
#endif
buffer_pos += vnp_raw_pack_string(&buf[buffer_pos], name, 16);
buffer_pos += vnp_raw_pack_string(&buf[buffer_pos], pass, 16);
{
void *con;
con = v_con_connect(address);
if(connection != NULL)
*connection = con;
}
v_cmd_buf_set_address_size(head, buffer_pos, buffer_pos);
v_nq_send_buf(v_con_get_network_queue(), head);
}head = v_cmd_buf_allocate(0); // is allocating 44 bytes.
buf = ((VCMDBuffer10 *)head)->buf; // buf = head+32, which leaves 12 bytes.
Then you pack an uint8 (1 byte), an uint32 (4 bytes), and two strings (up to 16 bytes each, but only 6 bytes each in this case, "eskil" and "nixon"). That is 17 bytes, but can be up to 37. This overruns the remaining 12 bytes.
The program doesn't actually crash at this point, but does later at:
v_con_connect() -> v_fs_create_func_storage() -> connection = malloc(sizeof *connection);
I'm still trying to fully understand what causes this overrun to cause a segmentation fault two malloc calls later.
By changin the buffer allocation to v_cmd_buf_allocate(1) (which allocates 84 bytes) in this case, v_test will run without errors.
I hope this helps. I remember in reading about debugging malloc calls, there is a way to enforce strict bounds checking, but it's slow. I'll have to look that up again.
All in all, by tweaking the buffer allocations, I have connector up and running. Yay! I can connect to and dissconnect from the server, create new nodes, hide, unhide... all that fun stuff.
The zoom isn't working, so it's REALLY hard to read the text (more like impossible ).Keep up the awesome work!
Ok I see the problem. I can fix it, I will get a new version up later today. the v_cmd_buf_allocate(0); command allocates different sizes of buffers for different commands. So the code that generates the commands computes how much space each command needs and chooses to allocate a buffer of the right size. How ever in commands using the INLINE functionality the code generator can not know how much space is needed and should choose the largest buffer. It should be an easy fix.
Thank you so much!
E
Thank you so much!
E
Ok its fixed!
It turns out the code was not written... I wrote a new func in the v_cmd_gen.c that computes the size of the commands, and writes them out as enums now (easier to read). I also fixed the double build problem, if you define:
#define V_GENERATE_FUNC_MODE
in v_cmd_gen.h the server will re-build all command definitions. Kind of fun...
Thanks again!
E
It turns out the code was not written... I wrote a new func in the v_cmd_gen.c that computes the size of the commands, and writes them out as enums now (easier to read). I also fixed the double build problem, if you define:
#define V_GENERATE_FUNC_MODE
in v_cmd_gen.h the server will re-build all command definitions. Kind of fun...
Thanks again!
E
Sorry about the huge delay.
http://www.quelsolaar.com/technology/verse2source.zip
But the new version is very nice, The API is now just about complete. And I would like any one who is interested in hacking to try to send packets to verse to make it crash.
I have sort of given up on doing huge amounts of tutorials (sorry). Instead I am working on a spec that contains everything, then if any one is interested in writing tutorials they can do that. If any one is desperate, mail me and i can send you advance copies of the spec, in progress.
E
http://www.quelsolaar.com/technology/verse2source.zip
But the new version is very nice, The API is now just about complete. And I would like any one who is interested in hacking to try to send packets to verse to make it crash.
I have sort of given up on doing huge amounts of tutorials (sorry). Instead I am working on a spec that contains everything, then if any one is interested in writing tutorials they can do that. If any one is desperate, mail me and i can send you advance copies of the spec, in progress.
E
amaricanisms? shouldnt that be usaisms?celeriac wrote:oh lordy mr eskil, your 3d modelling programs are things of beauty, but i beg you, please...americanisms like that are so ugly. 'bad' is an adjective, isn't it ?eskil wrote:...The empty files are just my bad...
it is 'my mistake' ;-]
Dont remember ever hearing any mexicans saying that,
-
Money_YaY!
- Posts: 442
- Joined: Wed Oct 23, 2002 2:47 pm
It's hip-hopisms http://www.zenhaiku.com/archives/is_my_bad_bad.htmlgreen wrote:amaricanisms? shouldnt that be usaisms?celeriac wrote:oh lordy mr eskil, your 3d modelling programs are things of beauty, but i beg you, please...americanisms like that are so ugly. 'bad' is an adjective, isn't it ?eskil wrote:...The empty files are just my bad...
it is 'my mistake' ;-]
Dont remember ever hearing any mexicans saying that,
word yo, fishys
^v^
It is very consciously. it something I do turn on and off.
I like playing around a lot with languages. Especially black English but rather pre 90s slang. can you dig it? "My bad" is one of very few newer expressions that i like. Saying "sorry" is sometime a little too serious, and that why i like "My bad", it more light hearted, like calling the mistake. And i don't think there is another good expression that captures that.
An if you don't like it, well then your bad.
E
"You know, a situation like this has a high potentiality for the common motherfucker to bitch out."
I like playing around a lot with languages. Especially black English but rather pre 90s slang. can you dig it? "My bad" is one of very few newer expressions that i like. Saying "sorry" is sometime a little too serious, and that why i like "My bad", it more light hearted, like calling the mistake. And i don't think there is another good expression that captures that.
An if you don't like it, well then your bad.
E
"You know, a situation like this has a high potentiality for the common motherfucker to bitch out."