ArrayIndexOutOfBoundsException is thrown despite the array index being well within bounds - audio

Alright,
This error first came up while using a for to load a bunch of songs I'd listed the titles of in a separate array, as shown below.
It is noteworthy that I'd run this sketch on an outdated version of the sound library, and that same line gave me an error the likes of "Gave up looking for a valid MPEG header after 65536 bytes of junk". If I only loaded one song, said error did not show up. Any more than that, and it did.
However, now that I updated the sound library, it gives me the ArrayIndexOutOfBounds exception: 3.
Which is not only odd because in the array I'm using the maximum index allowed should be 7 (as its length is 8), but also because I use the ArrayIndex 1. See below.
My attempts to get rid of (or at least isolate) the error can be seen in the code below.
If it can be of any use, I'm using Processing 3.5, latest update of the Sound library, and OS X 10.9.5 (spare your mockery).
String[] titles={"Small Bump", "This", "I See Fire", "The City ", "The City", "Cake By The Ocean", "Never Gonna Give You Up", "Innamoratissimo"};
SoundFile[] songs= new SoundFile[titles.length];
int i=0;
void setup(){
//for (int i=0; i<songs.length; i++) songs[i]=new SoundFile(this,titles[i]+".mp3");
//This one gave me a fault
//for (int i=0; i<1; i++) songs[i]=new SoundFile(this,titles[i]+".mp3");
//This one ran ok
//for (int i=0; i<2; i++) songs[i]=new SoundFile(this,titles[i]+".mp3");
//This one threw a fit again
//So I decided to list them manually to make sure the for wasn't doing funky stuff
songs[0]=new SoundFile(this,"Small Bump.mp3");
songs[1]=new SoundFile(this,"This.mp3"); //This is the line causing mayhem. See how the ArrayIndex is neither out of bounds nor 3?
}

Related

JSON.stringify causing weird read-only string on iteration attempt

I'm attempting to iterate a string but seem to be getting a weird access violation, The problem is caused when passing a value returned from JSON.stringify because the data seems to be read only, upon many attempts to use hacky methods to solve the issue I have not been successful in doing so.
I've tried copying the data, manually iterating the string and copying the string over to another variable, but the issue still remains the same no matter what I've tried.
The code below works flawlessly when a protected piece of data is not passed
xor_swap(keys, data)
{
for(var i = 0; i < data.length; i++)
data[i] ^= this.xor_key_exchange(keys, i);
return data.toString('utf8');
}
How ever when applying a parameter (for instance JSON.stringify), The data becomes protected and no matter what I seem to do the data seems to not be modifiable.
var enc = this.xor_swap(keys,JSON.stringify(data));
Please note that the input is completely correct, I have tested this many times.
Of-course the expected output is that the string should be iteratable, and after speaking to a few people who are very experienced in nodejs they can't seem to see why this problem is being caused.
I am not using strict-mode for anyone asking.
Thanks to anyone who can help me with this problem
In Javascript string is immutable. You cannot do the following
var a = 'hello';
a[1] = 'a' // try change 'e' to 'a', not possible
console.log(a)
JSON.stringify() returns a string which by definition is immutable.
So, this assignment here is invalid
data[i] ^= this.xor_key_exchange(keys, i);
thanks for your reply, I noticed that the conversion to a string is indeed immutable.
So I ended up solving this problem by simply converting the string to a buffer, completing my xor and then just converting the buffer directly back to a utf8 string again.
xor_swap(keys, data)
{
var buf = Buffer.from(data);
for(var i = 0; i < buf.length; i++)
buf[i] ^= Math.abs(this.xor_key_exchange(keys, i));
return buf.toString('utf8');
}
Thank you very much for your help

how to handle read access violation?

sorry for avoiding you guys
i have a problem with reverse function in circular linked list.
void reverse() {
int num = many;
node* current = head;
node* previous = 0;
while (num != 0) {
cout << "1" << '\t';
node* r = previous;
previous = current;
current = current->next;
previous->next = r;
num--;
}
head = previous;
}
in this func after 2 while sentence
problem comes up in line that current = current->next;
(exception throw : read access violation,
current was 0xDDDDDDDD)
how to handle it??
This is from Visual Studio trying to help you (and succeeding, IMO).
As Mark Ingraham pointed out in another answer a long time ago, Visual Studio's runtime library will fill a block of data with 0xDDDDDDDD when you release a block of heap memory.
So, although you haven't shown any code that's deleting from your list, if there is such code, that's probably the first place to look--at least at first glance, it looks like there's a fair chance that when you try erase a node from the list, you're deleting the memory the node lives in, but still leaving a pointer to that deleted memory.
It's also possible (but less likely, IMO) that you're just using memory without initializing it--and you happen to be hitting a block of memory that was previously allocated and then released back to the heap manager.
The bottom line, however, is that you don't "handle" the access violation. Instead, you need to find the bug in your code that's leading to the access violation happening, and fix it so that doesn't happen any more.

Filling QGraphicsScene with items in thread

I have the thread where the worker object is running infinite cycle. Here I have the following code that I would like it to read coordinates from list and place QGraphicsEllipseItem on these coordinates. The list can be updated by another thread, so I protect it by mutex. But sometimes the size of list may grow up so I would like to create new QGraphicsEllipse items for it if needed.
int meter_to_pixel_ratio = 20;
int x_pixel, y_pixel;
int i;
forever {
visualizationDataMutex->lock();
while(ellipseList->count()<visualizationData->count())
{
qDebug() << "Creating new visual item...";
ellipseList->append(new QGraphicsEllipseItem(0.0, 0.0, 10.0, 10.0));
ellipseList->last()->setVisible(false);
visualizationScene->addItem(ellipseList->last());
}
for(i=0; i<visualizationData->count(); i++)
{
x_pixel = meter_to_pixel_ratio*visualizationData->at(i)->x();
y_pixel = meter_to_pixel_ratio*visualizationData->at(i)->y();
ellipseList->at(i)->setPos(x_pixel, y_pixel);
ellipseList->at(i)->setBrush(QBrush(*visualizationColor->at(i)));
if(!ellipseList->at(i)->isVisible()) ellipseList->at(i)->setVisible(true);
}
visualizationDataMutex->unlock();
// repaint scene
visualizationScene->update();
QThread::msleep(100);
}
The problem I have is, that when I try to run the program I´ll obtain a runtime error. Tried to qDebug() the ellipseList->count() and seems to have the exactly same number of elements as needed (as visualizationData->count()). When commented these three lines:
//ellipseList->at(i)->setPos(x_pixel, y_pixel);
//ellipseList->at(i)->setBrush(QBrush(*visualizationColor->at(i)));
//if(!ellipseList->at(i)->isVisible()) ellipseList->at(i)->setVisible(true);
program can run without crashing. I do not understand why is this happening since there is no other function working with QGraphicsView/QGraphicsScene. (QGraphicsView was added from Qt Designer environment into mainwindow).

some doubts in the following code

have a look at the code below once and help me out by clarifying my doubts.
I have commented my doubts on each lines where i have doubts. Moreover, its a part of code from a huge one. so please ignore the variable declarations and all.
The whole code is working perfect and no errors while compiled.
double Graph::Dijkstra( path_t& path )
{
int* paths = new int[_size];
double min = dijkstra(paths); // **is a function call or not? bcz i didn't found any function in the code**
if(min < 0) { delete[] paths; return -1;}
int i = _size - 1;
while(i>=0)
{
path.push(i); // **when will the program come out of this while loop, i'm wondering how does it breaks?**
i=paths[i];
}
path.push(0);
delete[] paths;
return min;
}
Full coding is available here.
double min = dijkstra(paths); // **is a function call or not? bcz i didn't found any function in the code**
It almost certainly is. However, it could be a free function, member function, function invoked by a macro, or something else. Without seeing the rest of the code, we can only guess.
while(i>=0)
{
path.push(i); // **when will the program come out of this while loop, i'm wondering how does it breaks?**
i=paths[i];
}
The program will come out of the loop as a soon as i is less than zero. If I had to guess, I'd say the each node in the path contains a link to the previous node's index with the last node in a path returning -1 or some other negative number.

Optimize CoffeeScript-generated JS for V8

coffee-generated JS of the following simple code snippet:
console.log 'b' if 'b' in arr
is
var __indexOf = [].indexOf || function(item) {
for (var i = 0, l = this.length; i < l; i++) {
if (i in this && this[i] === item) return i;
} return -1;
};
if (__indexOf.call(arr, 'b') >= 0) {
console.log('b');
}
I can understand why it is so. IE doesn't support indexOf, and we want to make sure our CS code runs smoothly on all browsers. But, when writing the code for a Node.js server, we know exactly what the JS engine supports (ECMA-262, 5th edition), so we wouldn't need the above trick.
I'm not terribly familiar with different JavaScript implementations, but I'm sure it's not the only non-optimal code coffee -c produces because of browser incompatibilities, and if we consider all of them in a production server with thousands of concurrent connections, they add a considerable unnecessary overhead to the code.
Is there a way to remedy this? More and more Node.js code is written in CS these days, and with SourceMap on the horizon, the number would be even greater...
This is barely non-optimal; the __indexOf declaration is evaluated once, at the beginning, and it's immediately resolved to [].indexOf, i.e. using the underlying implementation's Array.prototype.indexOf. That's not exactly a huge expense, surely.
I'd need to see some other examples of "non-optimal" code, but I'm sure most of them fall into the same basket. Number of concurrent connections doesn't scale the effect of this at all.

Resources