Go Down

Topic: Help - Random function not working (Read 7025 times) previous topic - next topic

Berg

Quote
Is there anyone using 32-bit Linux experiencing this problem?


I believe I am (I've tried so many different versions on different computers lately, I can't remember which one I used last).

uname - a gives me
Linux ratatosk 2.6.27-9-generic #1 SMP Thu Nov 20 21:57:00 UTC 2008 i686 GNU/Linux

Saxdude

#16
Dec 18, 2008, 05:02 pm Last Edit: Dec 18, 2008, 05:16 pm by Saxdude Reason: 1
@mikalhart: my results are the same as yours, running SUSE 11.0 x86_64...

Code: [Select]
Linux polaris 2.6.25.18-0.2-default #1 SMP 2008-10-21 16:30:26 +0200 x86_64  GNU/Linux

Using arduino-0012 on a Duemilanove.

Veronica

#17
Dec 19, 2008, 04:01 pm Last Edit: Dec 19, 2008, 04:03 pm by vbu Reason: 1
Hi,

I'm not really familiar with how the arduino environment generates it's random numbers. However, if it's using openssl then there is a bug in Debian (and its derivatives e.g. Ubuntu) that may be the cause.

https://docs.astro.columbia.edu/ticket/793
http://www.us-cert.gov/cas/techalerts/TA08-137A.html

and for Ubuntu:
http://www.ubuntu.com/usn/usn-612-1

The latter gives the version numbers of fixed packages for openssl by distro version (e.g. Hardy). It also mentions that Intrepid (8.10) had this bug while it was under development.

Tonight I'll check what version of openssl my Ubuntu 8.10 install is using. However, since my ISP currently has connectivity issues (submarine cable fault), I may not be able to post my results until I get back to work on Monday.

Ver
(fixed punctuation  :P)

halley

Veronica, it's a similar concept, but I would be very surprised if OpenSSL used the libc implementation of rand().  When you get into cryptography, people really get extremely picky at the mathematical features of their random-number-generators.

If this were put into a car analogy, the OpenSSL guys are complaining that the tires have a weak tread pattern that might have trouble on ice, while the Arduino behavior seen above is like noticing that you have three flat tires and no engine.

Veronica

hmm, that makes sense halley, but it does seem, so far, as if its limited to debian distros maybe even just Ubuntu. Saxdude doesn't have the problem using SUSE 64 bit, whereas Berg (Kubuntu 8.10 32 bit) and I (Ubuntu 8.10 64 bit) do.

I don't have another linux distro to test on though I will try installing a vm with Centos to see if the problem still occurs.

Ver


mikalhart

Here's what I don't understand: what in the world do libc implementations on the host computer have to do with what is uploaded to the Arduino?  Perhaps my gcc-less Windows-centric world view inhibits my capacity to understand what is going on, but surely Arduino's libc is not just a subset extracted from the Linux host computer.  Or is it?  

Mikal

Chelmi

Quote
what in the world do libc implementations on the host computer have to do with what is uploaded to the Arduino


IMHO, nothing. But I might be wrong :)
The only way to understand what is going one is to look at the assembly file for the rand routine and see what is different between the one generated on linux 32/win/OSX and linux 64. Now that I'm in holiday I have more time to do it. I have a 64 bits ubuntu here. I did not run the test but expect to get the strange result. I might need to get a "working" elf file. Anybody can send me one?

Saxdude

What do you want an elf file of? mikalhart's sketch?

Wild guess: the arduino-0012 software was written for AMD64. Perhaps there's a snag hat occurs when running it on Intel 64 bit boxen?

Saxdude

Quote
what in the world do libc implementations on the host computer have to do with what is uploaded to the Arduino


FWIW, on SUSE 11.0 x86_64 we have:

avr-libc 1.6.1-25.1
glibc 2.8-14.1

Chelmi

#24
Dec 20, 2008, 06:05 pm Last Edit: Dec 20, 2008, 06:05 pm by chelmi Reason: 1
Quote
What do you want an elf file of? mikalhart's sketch?


Yes that would be perfect. Could you give me the version of your avr-libc, avr-gcc and avr-binutils ? with ubuntu/debian:
$ dpkg-query -s avr-libc
$ dpkg-query -s gcc-avr
$ dpkg-query -s binutils-avr

with other distributions, check your package manager.

Quote
Wild guess: the arduino-0012 software was written for AMD64. Perhaps there's a snag hat occurs when running it on Intel 64 bit boxen?


I'm running it on AMD64 and I confirm the bug. Anyway, the Arduino IDE is calling avr-gcc in the background. My theory is a bug in the avr-libc on ubuntu 64 bits. I'm compiling the last version to see if it's changing anything.

Chelmi, who loves is new detective job :)

Saxdude

Quote
Could you give me the version of your avr-libc, avr-gcc and avr-binutils ?


I have the following avr stuff installed:

cross-avr-gcc-4.1.3_20071030-39.1
cross-avr-binutils-2.18.50.20080409-12.1
avr-libc-1.6.1-25.1
avrdude-5.5-67.1

timmaah

Did anyone ever find a work around for this?

I thought I was going nuts for a while..

Running a 32 bit Ubuntu 8.10

Patzak

Since posting the original thread I have tried six different distros from three different vendors, in both 32 and 64 bit.  The difficulty is present in all forms.  The problem does not present itself in any other OS.  I have not found any Linux distro that does not produce this difficulty.  Even the code from Mikal, directly calling rand() produces the error.

westfw

Quote
What is different between OSX backends and Ubuntu backends, for the avr-gcc cross-compiled stdlib?

IIRC, the linux version requires that you install the avr tools by yourself, instead of packaging a particular compiler within the arduino app itself.

This would be a bug with the libc.a in use, since that seems to be where rand() lives.  (random() is in the Wiring Math library WMath.cpp, and it calls rand() from clib.)

mikalhart

Quote
(random() is in the Wiring Math library WMath.cpp, and it calls rand() from clib.)


@westfw-- just a quick observation that the random() my sketch was using is not the one in WMath.cpp, but one that lives alongside rand() in libc.  (Wiring's random() takes a parameter, but this one doesn't.)

Mikal

Go Up