Hello
I have BIG trouble with my library for libusb and I cant find any error in the source code :(
So if there is a library guru in here thats want to help me track down my error(s)..
I can compile the barebone library with no problem but I cant open the library without the system freezing, and the openlib program never returns.
I looks like it hangs in the library init function.
I have striped all the function to track down the nasty error
HELP PLEASE
The source files can be found here: http://www.rwo.dk/libusb.lha
Kind regards Rene W. Olsen
Rene W. Olsen wrote:
Hello
I have BIG trouble with my library for libusb and I cant find any error in the source code :(
So if there is a library guru in here thats want to help me track down my error(s)..
I can compile the barebone library with no problem but I cant open the library without the system freezing, and the openlib program never returns.
I looks like it hangs in the library init function.
I have striped all the function to track down the nasty error
HELP PLEASE
The source files can be found here: http://www.rwo.dk/libusb.lha
I am no guru, but one little thing... #include <proto/Libusb.h> in loadlib.c should have been #include <proto/libusb.h>. I will try to test it later, to see if I get some errors too (have tried to compile the library and loadlib with newlib instead, to see if it can be a little clib2 thing).
Kind regards Rene W. Olsen
Openoffice-os4 mailing list Openoffice-os4@samfundet.no https://lists.samfundet.no/mailman/listinfo/openoffice-os4
Henning Nielsen Lund wrote:
Rene W. Olsen wrote:
Hello
I have BIG trouble with my library for libusb and I cant find any error in the source code :(
So if there is a library guru in here thats want to help me track down my error(s)..
I can compile the barebone library with no problem but I cant open the library without the system freezing, and the openlib program never returns.
I looks like it hangs in the library init function.
I have striped all the function to track down the nasty error
HELP PLEASE
The source files can be found here: http://www.rwo.dk/libusb.lha
I am no guru, but one little thing... #include <proto/Libusb.h> in loadlib.c should have been #include <proto/libusb.h>. I will try to test it later, to see if I get some errors too (have tried to compile the library and loadlib with newlib instead, to see if it can be a little clib2 thing).
I did just try the one that I had recompiled using newlib (cross compiled)... it crashed :-( But as I have not tried to use newlib before with the crosscompiler, did I try to compile it nativly, and it worked :-D
LibusbBase 0283fc38 ILibusb 02857550 OK TheEnd
So at least loadlib is able to open libusb.library :-D
And remember if it is compiled using newlib.library, can the programs using the library also only use newlib.library as the standard-C library (the same goes for clib2).
Kind regards Rene W. Olsen
Openoffice-os4 mailing list Openoffice-os4@samfundet.no https://lists.samfundet.no/mailman/listinfo/openoffice-os4
On 2005/03/26, Henning Nielsen Lund wrote:
Henning Nielsen Lund wrote:
I am no guru, but one little thing... #include <proto/Libusb.h> in loadlib.c should have been #include <proto/libusb.h>. I will try to test it later, to see if I get some errors too (have tried to compile the library and loadlib with newlib instead, to see if it can be a little clib2 thing).
I did just try the one that I had recompiled using newlib (cross compiled)... it crashed :-( But as I have not tried to use newlib before with the crosscompiler, did I try to compile it nativly, and it worked :-D
LibusbBase 0283fc38 ILibusb 02857550 OK TheEnd
So at least loadlib is able to open libusb.library :-D
Okey then you get futher than me. I dont get any text at all
And remember if it is compiled using newlib.library, can the programs using the library also only use newlib.library as the standard-C library (the same goes for clib2).
I dident think of that, I guess that I am using clib2 but I dont think there any clib2 function in the library code.
Regards Rene
Rene W. Olsen wrote:
On 2005/03/26, Henning Nielsen Lund wrote:
Henning Nielsen Lund wrote:
I am no guru, but one little thing... #include <proto/Libusb.h> in loadlib.c should have been #include <proto/libusb.h>. I will try to test it later, to see if I get some errors too (have tried to compile the library and loadlib with newlib instead, to see if it can be a little clib2 thing).
I did just try the one that I had recompiled using newlib (cross compiled)... it crashed :-( But as I have not tried to use newlib before with the crosscompiler, did I try to compile it nativly, and it worked :-D
LibusbBase 0283fc38 ILibusb 02857550 OK TheEnd
So at least loadlib is able to open libusb.library :-D
Okey then you get futher than me. I dont get any text at all
And remember if it is compiled using newlib.library, can the programs using the library also only use newlib.library as the standard-C library (the same goes for clib2).
I dident think of that, I guess that I am using clib2 but I dont think there any clib2 function in the library code.
I thought that I saw something, but I might be wrong...
Regards Rene
Openoffice-os4 mailing list Openoffice-os4@samfundet.no https://lists.samfundet.no/mailman/listinfo/openoffice-os4
Rene W. Olsen wrote:
well now I just have to figure out where to open the device and I'm back on track.
Try to open it in the library's Open vector instead of the init code. The init code is executed on a separate thread within ramlib (under OS 4 at least). The open code is executed in the caller's context, so this is the better place to open it.
Regards,
ahh Happy day
I have spend some time, copying data from a working library to my libusb, I have check all include files and I have removed All code that werent used and now I can load the library :D
So what was the error..
In the library init function I try to open the usb device and that failes and never return (on my system)
well now I just have to figure out where to open the device and I'm back on track.
Regards Rene W. Olsen
Rene W. Olsen wrote:
I have been thinking about the sharing msgport and signal that is used in the open device and I dont really think its a good idea to share.. but where do I store the allocated stuff ?
You cannot easily share a signal between openers because the signal is task-specific, i.e. if you open from two different tasks then this will not work at all, not even if both tasks use the same signal bit because you cannot have a message port owned by two tasks.
Can I clone the libray base and return a clone to the user every time open lib is called?
It might be a better idea to have a "server process" that does the device handling, and communicate via messages with any opener. If you need to have opener-specific data, it might also be a better idea to do this in the interface instead of the library base - this is directly supported by the system and not as hacky in nature as cloning a library base.
Regards,
On 2005/03/30, Hans-Joerg Frieden wrote:
Try to open it in the library's Open vector instead of the init code. The init code is executed on a separate thread within ramlib (under OS 4 at least). The open code is executed in the caller's context, so this is the better place to open it.
I moved the open device into my librarys Manager_Open function and that worked nicely.
I have been thinking about the sharing msgport and signal that is used in the open device and I dont really think its a good idea to share.. but where do I store the allocated stuff ?
Can I clone the libray base and return a clone to the user every time open lib is called?
Regards Rene W. Olsen
Rene W. Olsen wrote:
I dont like the "server process" method... when moving lots of data that method will be really slow becorse it has to enter wait state so offen.
The problem is, like I said, that a device must be opened by the same task that is going to use it. A server process might not be a nice solution, but it *is* a solution to this problem.
It need not be slow either. You don't need to copy data. This will really only pose a problem if there is a lot of small data items being moved around.
I have looked at clone interface, this really looks promessing especially if I can use one of the reserved fields in InterfaceData struct as a userdata field..
No, you shouldn't use these. Use a data size. For example, something like this:
struct Foo { uint32 field1; void *field2; char field3[20]; float field4; };
During creation of the interface, pass
MIT_Flags, IFLF_PRIVATE, MIT_DataSize, sizeof(struct Foo),
In your method, use
struct Foo *instanceData = (struct Foo *)((uint8 *)Self -sizeof(struct Foo));
to obtain the private instance data of your interface (looking at this I guess we should add a macro for that to the header file ;-)
Best regards,
On 2005/03/31, Hans-Joerg Frieden wrote:
It might be a better idea to have a "server process" that does the device handling, and communicate via messages with any opener. If you need to have opener-specific data, it might also be a better idea to do this in the interface instead of the library base - this is directly supported by the system and not as hacky in nature as cloning a library base.
I dont like the "server process" method... when moving lots of data that method will be really slow becorse it has to enter wait state so offen.
I have looked at clone interface, this really looks promessing especially if I can use one of the reserved fields in InterfaceData struct as a userdata field..
Regards Rene W. Olsen
On 2005/03/31, Hans-Joerg Frieden wrote:
During creation of the interface, pass
MIT_Flags, IFLF_PRIVATE, MIT_DataSize, sizeof(struct Foo),
If I enable the IFLF_PRIVATE flag my GetInterface failes... looks like I need to use Clone/Expunge.
Can you point me to an example?
Regards Rene W. Olsen
Rene W. Olsen wrote:
If I enable the IFLF_PRIVATE flag my GetInterface failes... looks like I need to use Clone/Expunge.
Can you point me to an example?
Hmm, I thought that the default Clone would be sufficient... I'll have to check that.
Regards,
Hi,
Rene W. Olsen wrote:
If I enable the IFLF_PRIVATE flag my GetInterface failes... looks like I need to use Clone/Expunge.
Can you point me to an example?
I've uploaded a file to the development section's file are (testlib.lha). Note that this is a pretty bad example since it still contains bugs, but I lack the time to come up with a better one.
Regards,
Hi,
Rene W. Olsen wrote:
Now I have found whats is wrong.. if I calles my main interface "main" I get an extra Obtain() call like this [...] So that do I do know?
What you see is an oversight in Exec: Normally, old libraries provide a main interface with all the previous functionality, named "main". When calling OpenLibrary, it automatically executes GetInterface(.., "main", ...), since this is used by legacy jump tables.
To prevent this from happening, add the tag item
CLT_NoLegacyIFace, TRUE,
to the CreateLibrary tag list.
I'm not sure, though, if that's already in the released kernel. You might want to add the tag nontheless (it's not rejected because of this). If it's not part of your header files, it's defined as
#define CLT_NoLegacyIFace (TAG_USER + 12)
If in doubt, give the interface a meaninngful name. In the case of libusb, "usb" might be a good idea.
Regards,
On 2005/04/01, Thomas Frieden wrote:
I've uploaded a file to the development section's file are (testlib.lha). Note that this is a pretty bad example since it still contains bugs, but I lack the time to come up with a better one.
Many thanks for this and it works
Okey now I have almost used 2 days trying too make my library do that same as you did with little luck :(
Now I have found whats is wrong.. if I calles my main interface "main" I get an extra Obtain() call like this
_main_Obtain() RefCount = 1 _manager_Open() _main_Clone() RefCount = 1 _main_Obtain() RefCount = 2 _main_Clone() RefCount = 1 _main_Obtain() RefCount = 2 _main_Clone() RefCount = 1 _main_Obtain() RefCount = 2 _main_Release() _main_Release() _main_Release() _manager_Close() _manager_Expunge()
Resulting in my RefCount being one highere than it should be and that means my interfaces never gets Expunge()'d, and futher my interface get too calls to free my orginal interface twice meaning an Aleart about mem freed twice guru...
If I rename the interface from "main" to "tmain" like yours every things work nicely no extra Obtain().. see
_manager_Open() _main_Clone() RefCount = 0 _main_Obtain() RefCount = 1 _main_Clone() RefCount = 0 _main_Obtain() RefCount = 1 _main_Clone() RefCount = 0 _main_Obtain() RefCount = 1 _main_Release() _main_Release()->Expunge() _main_Expunge() _main_Release() _main_Release()->Expunge() _main_Expunge() _main_Release() _main_Release()->Expunge() _main_Expunge() _manager_Close() _manager_Expunge()
So that do I do know?
Regards Rene W. Olsen
On 2005/04/03, Thomas Frieden wrote:
What you see is an oversight in Exec: Normally, old libraries provide a main interface with all the previous functionality, named "main". When calling OpenLibrary, it automatically executes GetInterface(.., "main", ...), since this is used by legacy jump tables.
ahh okey
To prevent this from happening, add the tag item
CLT_NoLegacyIFace, TRUE,
to the CreateLibrary tag list.
Added and it did the trick
I'm not sure, though, if that's already in the released kernel. You might want to add the tag nontheless (it's not rejected because of this). If it's not part of your header files, it's defined as
#define CLT_NoLegacyIFace (TAG_USER + 12)
Yep its in my realease
If in doubt, give the interface a meaninngful name. In the case of libusb, "usb" might be a good idea.
I prepeare 'main'
I know I have been a pain in the butt so many thanks fore your and your brothers help, now I can get back to porting (I hope)
Regards Rene W. Olsen
Le 03/04/2005, Rene W. Olsen a écrit :
I know I have been a pain in the butt so many thanks fore your and your brothers help, now I can get back to porting (I hope)
I rather suspect you don't qualify for the title. A true PIB asks questions and creates nothing. Not your case. Go away, and if you can't think of a better way of denigrating yourself, port another app ;)
Salutations
On 2005/04/03, Rose Humphrey wrote:
Le 03/04/2005, Rene W. Olsen a écrit :
I know I have been a pain in the butt so many thanks fore your and your brothers help, now I can get back to porting (I hope)
I rather suspect you don't qualify for the title. A true PIB asks questions and creates nothing. Not your case. Go away, and if you can't think of a better way of denigrating yourself, port another app ;)
So fare I havent created any thing but I took youre advise and ported a test programe for libusb now I only have to finish the library :)
Regards Rene W. Olsen
-
Hans-Joerg Frieden -
Henning Nielsen Lund -
Rene W. Olsen -
Rose Humphrey -
Thomas Frieden