segmentation fault / OSC

Bozelos Dimitris

23 Mar 2009 23 Mar '09

6:01 p.m.

Hi again guys, I've run into some more problems in my brief acquaintance with ChucK (although it's definitely fun!). For some reason I constantly get a "segmentation fault" fatal error sometimes just after some seconds I run my shreds. What does this mean? I do something that might be silly, I send/receive parameters between shreds using OscEvents, can this cause the problem? Is there another way of communicating (exchanging control signals in this case) between processes? Once or twice I had an "OSC packet ...: buffer (or stack) overflow" error. Is there a buffer or a limit on the messages you send / receive? Can I somehow declare global variables? I checked the documentation and I didn't find anything. If the problem is because of excessive use of OSC I could maybe read/write global variables. Cheers, Dimitri ___________________________________________________________ Χρησιμοποιείτε Yahoo!; Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://login.yahoo.com/config/mail?.intl=gr

Attachments:

attachment.html (text/html — 1.3 KB)

Show replies by date

Kassen

23 Mar 23 Mar

7:19 p.m.

Hey, Dimitris!

...

For some reason I constantly get a "segmentation fault" fatal error sometimes just after some seconds I run my shreds. What does this mean?

Typically it means you tried to address something that doesn't exist/ isn't instantiated. It can also mean there is some bug in ChucK that affects you.

...

I do something that might be silly, I send/receive parameters between shreds using OscEvents, can this cause the problem?

I'm sure it can cause problems but it's no silly at all, this should work fine.

...

Is there another way of communicating (exchanging control signals in this case) between processes?

Sure; you can make a public class that has static members. For example a static Event in a public class can be used to send information across the while VM. This can be useful for many things and can make your code a lot more modular. Unless you want to experiment with OSC, for example because you want to involve a second computer and/or musician this may be the most simple way to go. For one thing ChucK's events are "strongly timed" while OSC depends on the host OS to pass on the data. Do note that static non-primitives can't be instantiated in classes right now so you will need a workaround like in this example; //------------------------- public class Message { static Event @ event; static int data1; static float data2; } new Event @=> Message.event; //-------------------------------

...

Once or twice I had an "OSC packet ...: buffer (or stack) overflow" error. Is there a buffer or a limit on the messages you send / receive?

I don't know :¬) I'm certain there must be some limit somewhere but I'm not sure what or where it is.

...

Can I somehow declare global variables? I checked the documentation and I

didn't find anything. If the problem is because of excessive use of OSC I could maybe read/write global variables. Sure! data1&2 in the above example will act as global variables. They will be the same across all instances of the class, regardless of what file they are in. they are NOT constant; any of those files may read them or write to them, just like any of those files may signal, broadcast or wait for Message.event I think that should get you started, do shout if this was unclear. This is a slightly hackish workaround for the current situation, at some point it should be fixed. On the bad side; it has been like this for quite a while now, on the good; it's quite workable like this once you get the hang of it. Hope that helps. Kas.

Bozelos Dimitris

30 Mar 30 Mar

12:37 p.m.

Hi Kassen, thanks a lot and sorry for the late reply I had trouble last days with the latest fedora updates and wouldn't ChucK that much! FROM: Kassen Hey, Dimitris!

...

For some reason I constantly get a "segmentation fault" fatal error sometimes just after some seconds I run my shreds. What does this mean?

Typically it means you tried to address something that doesn't exist/ isn't instantiated. It can also mean there is some bug in ChucK that affects you. Well, I found out that an accumulator that I had was causing the trouble. I was receiving a variable through osc and doing (inside an infinite time-loop) something like while( event.nextMsg() ) { event.getFloat() +=> a; } I don't really know why it was crushing, it shouldn't. when I removed this part everything was ok.

...

Once or twice I had an "OSC packet ...: buffer (or stack) overflow" error. Is there a buffer or a limit on the messages you send / receive?

I don't know :¬) I'm certain there must be some limit somewhere but I'm not sure what or where it is. What probably happened here is that I was being sent the messages faster than receiving them, so if I had an osc message coming every 100 ms and I had while( true ) { while( event.nextMsg() ) { ... } 1000::ms => now; } the messages might have been accumulating so there was the buffer overflow. Although it shouldn't be, I think. But I actually have a question here about the OSC events: is there any smart way to have some code executed on an event independently of the time of the infinite time-loop? To be more clear, let's say I have an BiQuad filter and I want to control its frequency over the network through OSC. So, while( true ) { while( event.nextMsg() ) { event.getFloat() => f.pfreq; } // do other stuff 1::second => now; } This have the consequence, if I'm not mistaken, that every 1 second chuck will check for new messages and if messages are sent every 300 ms and for some reason we need the loop to run every one second the frequency is actually updated once a second with the last of the 3 received values instead of 3 times a second. The only way around I can think now is to declare the filter in a public class as a static object and have a separate shred that runs with a faster time-loop and update the filter this way. But this might lead to unreasonable many shreds like one for gain, one for frequency etc. Moreover this will mean that I will be able to have only one BiQuad filter working this way. So I see this solution highly problematic. Any ideas? Thanks again, Dimitris ___________________________________________________________ Χρησιμοποιείτε Yahoo!; Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://login.yahoo.com/config/mail?.intl=gr

Stephen Sinclair

1:09 p.m.

2009/3/30 Bozelos Dimitris :

...

Hi Kassen,

thanks a lot and sorry for the late reply I had trouble last days with the latest fedora updates and wouldn't ChucK that much!

FROM: Kassen

Hey, Dimitris!

...
For some reason I constantly get a "segmentation fault" fatal error sometimes just after some seconds I run my shreds. What does this mean?

Typically it means you tried to address something that doesn't exist/ isn't instantiated. It can also mean there is some bug in ChucK that affects you.

Well, I found out that an accumulator that I had was causing the trouble. I was receiving a variable through osc and doing (inside an infinite time-loop) something like

while( event.nextMsg() ) {     event.getFloat() +=> a; }

I don't really know why it was crushing, it shouldn't. when I removed this part everything was ok.

...
Once or twice I had an "OSC packet ...: buffer (or stack) overflow" error. Is there a buffer or a limit on the messages you send / receive?

I don't know :¬) I'm certain there must be some limit somewhere but I'm not sure what or where it is.

What probably happened here is that I was being sent the messages faster than receiving them, so if I had an osc message coming every 100 ms and I had

while( true ) {     while( event.nextMsg() ) { ... }     1000::ms => now; }

the messages might have been accumulating so there was the buffer overflow. Although it shouldn't be, I think.

But I actually have a question here about the OSC events: is there any smart way to have some code executed on an event independently of the time of the infinite time-loop? To be more clear, let's say I have an BiQuad filter and I want to control its frequency over the network through OSC. So,

while( true ) {     while( event.nextMsg() )     {         event.getFloat() => f.pfreq;     }

    // do other stuff

    1::second => now; }

This have the consequence, if I'm not mistaken, that every 1 second chuck will check for new messages and if messages are sent every 300 ms and for some reason we need the loop to run every one second the frequency is actually updated once a second with the last of the 3 received values instead of 3 times a second.

The only way around I can think now is to declare the filter in a public class as a static object and have a separate shred that runs with a faster time-loop and update the filter this way. But this might lead to unreasonable many shreds like one for gain, one for frequency etc. Moreover this will mean that I will be able to have only one BiQuad filter working this way. So I see this solution highly problematic. Any ideas?

Yo, You can wait on the event itself, so that your loop will wake up every time a message comes in. while( true ) { while( event.nextMsg() ) { event.getFloat() => f.pfreq; } 1::second => now; } If you need to "do other stuff", I suggest doing this event loop in a shred by sporking it. Steve

Stephen Sinclair

1:12 p.m.

On Mon, Mar 30, 2009 at 1:09 PM, Stephen Sinclair wrote:

...

2009/3/30 Bozelos Dimitris :

...
Hi Kassen,

thanks a lot and sorry for the late reply I had trouble last days with the latest fedora updates and wouldn't ChucK that much!

FROM: Kassen

Hey, Dimitris!

...
For some reason I constantly get a "segmentation fault" fatal error sometimes just after some seconds I run my shreds. What does this mean?

Typically it means you tried to address something that doesn't exist/ isn't instantiated. It can also mean there is some bug in ChucK that affects you.

Well, I found out that an accumulator that I had was causing the trouble. I was receiving a variable through osc and doing (inside an infinite time-loop) something like

while( event.nextMsg() ) {     event.getFloat() +=> a; }

I don't really know why it was crushing, it shouldn't. when I removed this part everything was ok.

...
Once or twice I had an "OSC packet ...: buffer (or stack) overflow" error. Is there a buffer or a limit on the messages you send / receive?

I don't know :¬) I'm certain there must be some limit somewhere but I'm not sure what or where it is.

What probably happened here is that I was being sent the messages faster than receiving them, so if I had an osc message coming every 100 ms and I had

while( true ) {     while( event.nextMsg() ) { ... }     1000::ms => now; }

the messages might have been accumulating so there was the buffer overflow. Although it shouldn't be, I think.

But I actually have a question here about the OSC events: is there any smart way to have some code executed on an event independently of the time of the infinite time-loop? To be more clear, let's say I have an BiQuad filter and I want to control its frequency over the network through OSC. So,

while( true ) {     while( event.nextMsg() )     {         event.getFloat() => f.pfreq;     }

    // do other stuff

    1::second => now; }

This have the consequence, if I'm not mistaken, that every 1 second chuck will check for new messages and if messages are sent every 300 ms and for some reason we need the loop to run every one second the frequency is actually updated once a second with the last of the 3 received values instead of 3 times a second.

The only way around I can think now is to declare the filter in a public class as a static object and have a separate shred that runs with a faster time-loop and update the filter this way. But this might lead to unreasonable many shreds like one for gain, one for frequency etc. Moreover this will mean that I will be able to have only one BiQuad filter working this way. So I see this solution highly problematic. Any ideas?

Yo,

You can wait on the event itself, so that your loop will wake up every time a message comes in.

while( true ) { while( event.nextMsg() ) { event.getFloat() => f.pfreq; } 1::second => now; }

If you need to "do other stuff", I suggest doing this event loop in a shred by sporking it.

Sorry, I intended to change the code after copying it: fun void msg_freq() { while( true ) { event => now; while( event.nextMsg() ) { event.getFloat() => f.pfreq; } } } spork ~ msg_freq();

Stefan Blixt

4:37 p.m.

I have a faint memory that I have run into problems when not reading all parameters that are included in an event, or mismatching the actual event with the parameter list in the OscRecv constructor, or something. Say that whatever sends the OSC event that you are receiving in your code, Dimitris, adds two float parameters. You only read one, so the other remains somewhere. I can't reproduce this now locally, so I may just be rambling. A thought anyway. /Stefan On Mon, Mar 30, 2009 at 7:12 PM, Stephen Sinclair wrote:

...

...
2009/3/30 Bozelos Dimitris :

...
Hi Kassen,

thanks a lot and sorry for the late reply I had trouble last days with

...
...
latest fedora updates and wouldn't ChucK that much!

FROM: Kassen

Hey, Dimitris!

...
For some reason I constantly get a "segmentation fault" fatal error sometimes just after some seconds I run my shreds. What does this mean?

Typically it means you tried to address something that doesn't exist/ isn't instantiated. It can also mean there is some bug in ChucK that affects you.

Well, I found out that an accumulator that I had was causing the

...
...
was receiving a variable through osc and doing (inside an infinite time-loop) something like

while( event.nextMsg() ) { event.getFloat() +=> a; }

I don't really know why it was crushing, it shouldn't. when I removed

...
...
part everything was ok.

...
Once or twice I had an "OSC packet ...: buffer (or stack) overflow" error. Is there a buffer or a limit on the messages you send / receive?

I don't know :¬) I'm certain there must be some limit somewhere but I'm not sure what or where it is.

What probably happened here is that I was being sent the messages faster than receiving them, so if I had an osc message coming every 100 ms and I had

while( true ) { while( event.nextMsg() ) { ... } 1000::ms => now; }

the messages might have been accumulating so there was the buffer overflow. Although it shouldn't be, I think.

But I actually have a question here about the OSC events: is there any smart way to have some code executed on an event independently of the time of

On Mon, Mar 30, 2009 at 1:09 PM, Stephen Sinclair wrote: the trouble. I this the

...
...
infinite time-loop? To be more clear, let's say I have an BiQuad filter and I want to control its frequency over the network through OSC. So,

while( true ) { while( event.nextMsg() ) { event.getFloat() => f.pfreq; }

// do other stuff

1::second => now; }

This have the consequence, if I'm not mistaken, that every 1 second chuck will check for new messages and if messages are sent every 300 ms and for some reason we need the loop to run every one second the frequency is actually updated once a second with the last of the 3 received values instead of 3 times a second.

The only way around I can think now is to declare the filter in a public class as a static object and have a separate shred that runs with a faster time-loop and update the filter this way. But this might lead to unreasonable many shreds like one for gain, one for frequency etc. Moreover this will mean that I will be able to have only one BiQuad filter working this way. So I see this solution highly problematic. Any ideas?

Yo,

You can wait on the event itself, so that your loop will wake up every time a message comes in.

while( true ) { while( event.nextMsg() ) { event.getFloat() => f.pfreq; } 1::second => now; }

If you need to "do other stuff", I suggest doing this event loop in a shred by sporking it.

Sorry, I intended to change the code after copying it:

fun void msg_freq() { while( true ) { event => now; while( event.nextMsg() ) { event.getFloat() => f.pfreq; } } }

spork ~ msg_freq(); _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- Release me, insect, or I will destroy the Cosmos!

Bozelos Dimitris

4 Apr 4 Apr

8:22 a.m.

Hi Stefan, thanks for the suggeastion. It could be, I was sending OSC from SuperCollider so there might be some mismatch in the format or something. I do remember having less problems when sending/receiving OSC within ChucK itself. Cheers, Dimitris --- Στις Δευτ., 30/03/09, ο/η Stefan Blixt έγραψε:

...

Από: Stefan Blixt

...

I have a faint memory that I have run into problems when not reading all parameters that are included in an event, or mismatching the actual event with the parameter list in the OscRecv constructor, or something. Say that whatever sends the OSC event that you are receiving in your code, Dimitris, adds two float parameters. You only read one, so the other remains somewhere. I can't reproduce this now locally, so I may just be rambling. A thought anyway.

/Stefan

___________________________________________________________ Χρησιμοποιείτε Yahoo!; Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://login.yahoo.com/config/mail?.intl=gr

Bozelos Dimitris

8:17 a.m.

Hey Stephen, thanks that's great!! It should do what I need, I didn't think about it.. Dimitris --- Στις Δευτ., 30/03/09, ο/η Stephen Sinclair έγραψε:

...

Από: Stephen Sinclair

...
Yo,

You can wait on the event itself, so that your loop

will wake up every

...
time a message comes in.

while( true ) { while( event.nextMsg() ) { event.getFloat() => f.pfreq; } 1::second => now; }

If you need to "do other stuff", I suggest doing this event loop in a shred by sporking it.

Sorry, I intended to change the code after copying it:

fun void msg_freq() { while( true ) { event => now; while( event.nextMsg() ) { event.getFloat() => f.pfreq; } } }

spork ~ msg_freq();

5572

Age (days ago)

5584

Last active (days ago)

List overview

Download

7 comments

4 participants

participants (4)

Bozelos Dimitris
Kassen
Stefan Blixt
Stephen Sinclair

segmentation fault / OSC

tags

participants (4)