September 2005 - openSUSE Programming - openSUSE Mailing Lists

Base Class Repository
by cjtaylor_mail-suse＠yahoo.com 08 Oct '05

08 Oct '05

Is there a site that contains c++ base classes. I am looking to develop an application that is multithreaded. I am hoping that there is a base class available that has the thread capabilities, message queues, and signal processing. This is not for a class. This is for a utility to display ascii string sent via udp from an embedded device to aid in debugging. Any help is appreciated. Chris Taylor

3 3

Re: [suse-programming-e] valgrind detects false memleak?
by Verdi March 21 Sep '05

21 Sep '05

> In your pseado code r is a local variable. Does the > function go out of scope before the ProcessRequest() > gets called? If so, this is where the leak could be. Yup, it's pointer, so shouldn't be out of scope thing. When processRequest() is called, it'll be able to refer to the correct request. Regards, Verdi -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen f�r GMX Partner: http://www.gmx.net/de/go/partner

1 0

Re: [suse-programming-e] valgrind detects false memleak?
by Verdi March 21 Sep '05

21 Sep '05

cjtaylor_mail-suse(a)yahoo.com wrote: > In your pseado code r is a local variable. Does the > function go out of scope before the ProcessRequest() > gets called? If so, this is where the leak could be. IIRC its a pointer. But I'll check again later, when I return to my lab. Regards, Verdi -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen f�r GMX Partner: http://www.gmx.net/de/go/partner

1 0

valgrind detects false memleak?
by Verdi March 21 Sep '05

21 Sep '05

Hi, Valgrind reports a memory leak on my program for certain variable. To find out on what case I fail to free variable, I printed some messages before the allocation/deallocation of the relevant variable, say printf("ALLOC\n") before calloc and printf("FREE\n") after free. The funny thing is, when I ran and counted the number of messages, there was equal number of ALLOC messages and FREE messages. Which mean, no memory leak at all. Right now I assume that valgrind falsely detect some memleaks. However, this leaves me some uncomfortable feeling, as if sometime later, my program will cause the computer to explode (ok, exaggeration here :). Any thoughts on that? Btw, I use the standard calloc/free provided by glibc, not some 3rd party ones. TIA. Regards, Verdi -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse f�r Mail, Message, More +++

3 5

system-dependent behaviour
by Verdi March 17 Sep '05

17 Sep '05

Hi, Just want to confirm that the following statements is 'dangerous', in the sense that it's system dependant. I recall to read somewhere there're additional case where this can happen, such as dofun(s, s++). Any insight on why it happens is highly appreciated. Here's the program: int main(void) { int s=3; printf("s=%i,s=%i,s=%i\n",s,s++,s--); return 0; } For the result, I got s=3,s=2,s=3 on SuSE 9.3, but on a Solaris machine, I got s=3,s=3,s=4. Regards, Verdi -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++

7 33

Unable to load shared library (signature?)
by Pierre Patino 17 Sep '05

17 Sep '05

Greetings I've just emerged from a full day of hacking. It all started when I downloaded the latest update for SuSE 9.3. Along with everything else I accepted the kernel update (2.6.11.4-21.9-default) knowing full well I would have to deal with another iteration of the nvidia graphics driver download. After all the updates were properly sucked in and disseminated, I rebooted my computer. All of the boot sequence went well. However, the machine went into an endless login loop: while (1) { show login screen for 800ms clear screen } I was able to CTRL-ALT-BACKSPACE to get to a non-graphics login and then tried to figure out what was happening. startx would exit saying that kdeconfigure or some other binary in /opt/kde3/bin would fail. Upon closer examination, I was able to determine that the kde applications would complain of being "unable to load shared library lxxxxx.so.xxx". I used ldd, export LD_DEBUG=all, strace -f and other utilities to determine that the binary was unable to load the libkxxxx.so.y library. However, I was able to find the library manually at exactly the same location that the binary was complaining about. For example, I would see in strace: ... open("/lib64/libkxxxx.so.4", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\21\0"..., 640) = 640 ... "/lib64/libkxxxx.so.4 not found!" (or something like that) ..... ls -la /lib64/libkxxxx.so.4 had not problems finding the file with wide open permissions. After trying many other fruitless paths, I was able to recover by pointing /opt/kde3 to an older partition. I assume that even though the shared object files were found, they must have lacked some signature Questions: Is there some fine-grained tool that would have told me sooner what was going on? Am I the only one that has gone through this torture? TIA& Cheers P.S. Am I blowing etiquette by posting on two groups?

3 3

RE: [suse-programming-e] serial port overrun
by Francois Maletras 07 Sep '05

07 Sep '05

> > What would you get? Just wondering if the problem is at > > the tty driver (which probably hasn't changed in eons) , whatever > > mass-storage device driver that you're dumping data to or something else in the kernel. The driver module for the USB converter (usbserial) attached itself to ttyUSB0 and it works very well, so I am inclined to think that tty not an issue here. > > While the program is running, take a peek at /proc/interrupts too. yep! I could see UART activity on IRQ4. > I'm about to leave work for the weekend, but you should use > termios to make sure that you set the serial port to use flow control. Hope you had a good week end! I did indeed use termios (My book told me too) although not dead sure it was activated. You suggested getting the oscilloscope out... err, maybe another time. > If your program uses hardware flow control and the device > uses hardware flow control, you should not have any buffer overrun problems. Since using USB converter, the data upload takes 30seconds, i.e. 2 more seconds than before with the same baudrate and the same port configuration. How do you explain that??? USB is not the weakest link since it is natively faster than legacy serial. So, the explanation is perhaps that the uploads breaks and resumes, indicating that hardware flow control is now in place. Another question: I read on the Agilent website that Microsoft never implemented a true hardware flow control for the UART with Windows, but instead used another software layer to virtualise the control of flow signals. The reason apparently was that, when windows 3.1 came out, they could not unify all UARTs variants given that they all behaved a bit differently with respect to flow control signals. But, even though PC hardware is now a lot more uinified, they have kept this way of handling flow control. Is this right? I presume this is not the case with Linux? ------------------------------------------------------------------- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Serco House, 16 Bartley Wood Business Park, Hook, Hampshire, United Kingdom RG27 9UY -------------------------------------------------------------------

2 1

RE: [suse-programming-e] serial port overrun
by Francois Maletras 03 Sep '05

03 Sep '05

> > The c code is a simple user program with canonical reads in > a for loop. > > Looking at console tty10 during an upload from device to > computer, you > > get ttyS0: 1 input overrun(s) > > ttyS0: 2 input overrun(s) > > ttyS0: 1 input overrun(s) > > > > In average, you get 3~4 overruns per upload, but it can > drop to 1 or 0. > One of the things you really need to do is to get a serial > port analyzer. I > have not used one in years, but the ones we used were > breakout boxes. Not > only do these have the capability to change pins, bit they > also have leds. > You really want to see if the hardware flow control is > actually working or > not. > I have not done any serial port programming in a number of > years, but you > can really pull your hair out trying to debug this stuff. It is also very time consuming to sort out, especially with intermitent problems . I have actually stumbled accross a solution by using a USB to serial converter instead of the onboard 16550A UART. See http://www.ftdichip.com/Products/FTEvaluationKits.htm The UART in the converter has 384 bytes of Rx buffer, a far cry from the mere 16 bytes of the 16550A. Now works very reliably at 115200 bauds! ------------------------------------------------------------------- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Serco House, 16 Bartley Wood Business Park, Hook, Hampshire, United Kingdom RG27 9UY -------------------------------------------------------------------

3 3

RE: [suse-programming-e] serial port overrun
by Francois Maletras 02 Sep '05

02 Sep '05

> >I have this classic but very annoying problem with the UART > since upgrading from 9.0 to 9.3: > >It seems that the kernel has become unable to service IRQs > from the UART fast enough. > > > >This results in buffer overflows: During a bulk dump > (256kBytes) from serial device to disk, > >the UART (16550A) will overflows typically 2 or 3 times, > even though computer seems idle. > > > >The setup is arcom gx1, National Semi Geode 300MHz, 40 GB, 128 MB. > >The box is used to talk to an acquisition instrument through > RS232 at 115200 bauds, > >with hardware flow control turned on. > > > >Neither the BIOS, the HDD or the C code for talking to the > UART have changed during the > >transition from 9.0 to 9.3 so I am pretty convinced this > could be a kernel config problem. > > > >Are there any kernel config parameters that could help > servicing the UART more efficiently? > >I know this is a bit off-topic but any suggestions are welcome. > > > > > > > Is the C-code you're talking about a user program that opens the > /dev/ttySx port and loops on select() read() or do you have > your own driver? > What does dmesg say? The c code is a simple user program with canonical reads in a for loop. Looking at console tty10 during an upload from device to computer, you get ttyS0: 1 input overrun(s) ttyS0: 2 input overrun(s) ttyS0: 1 input overrun(s) In average, you get 3~4 overruns per upload, but it can drop to 1 or 0. ------------------------------------------------------------------- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Serco House, 16 Bartley Wood Business Park, Hook, Hampshire, United Kingdom RG27 9UY -------------------------------------------------------------------

2 1

serial port overrun
by Francois Maletras 01 Sep '05

01 Sep '05

Hi I have this classic but very annoying problem with the UART since upgrading from 9.0 to 9.3: It seems that the kernel has become unable to service IRQs from the UART fast enough. This results in buffer overflows: During a bulk dump (256kBytes) from serial device to disk, the UART (16550A) will overflows typically 2 or 3 times, even though computer seems idle. The setup is arcom gx1, National Semi Geode 300MHz, 40 GB, 128 MB. The box is used to talk to an acquisition instrument through RS232 at 115200 bauds, with hardware flow control turned on. Neither the BIOS, the HDD or the C code for talking to the UART have changed during the transition from 9.0 to 9.3 so I am pretty convinced this could be a kernel config problem. Are there any kernel config parameters that could help servicing the UART more efficiently? I know this is a bit off-topic but any suggestions are welcome. Francois ------------------------------------------------------------------- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Serco House, 16 Bartley Wood Business Park, Hook, Hampshire, United Kingdom RG27 9UY -------------------------------------------------------------------

2 1