Author Topic: BxbAsm  (Read 178793 times)

SteveA

  • Guest
Re: BxbAsm
« Reply #315 on: May 24, 2012, 06:18:59 AM »
Would there be any free/reallocate involved?
I can't track it down but I believe Win7 is very fussy on free, maybe even to the point of an actual bug??
I did a number of searches but couldn't come up with a definitive answer.

Yes.
I spent all day yesterday trying to figure out exactly what is going on.
I spent a good amount of time single-stepping thru Ollydebug, monitoring the registers and memory locations.

When a crash occurs, it's never while in the bxbasm module, but, rather in the ntdll.dll module.
I have become quite familiar with the breaking point, but, don't know what the exact cause is.
I can see everything is fine and then all of a sudden, a call to "free" goes off to never-never land.
It's the same everytime. Quite interesting.

It isn't as tho I have the wrong instruction, a mov, a push, a pop, etc., out of place.
The bxbasm code is correct.

Steve

SteveA

  • Guest
Re: BxbAsm
« Reply #316 on: May 24, 2012, 11:03:06 AM »
Okay,
I think I have it figured out.
It turns out that when "clear" is called, it is attempting to "free" some pointers.

For instance, this statement:     FIELD #1, 4 AS A$, 4 AS B$, 8 AS C1$, 8 AS D$, 10 AS E$
sets up an I/O buffer and the string-var names point to segments within the buffer.

Example:
    OPEN "R", #1, "test.txt", 34
establishes that the buffer is 34 bytes in size.

And, this statement:
    FIELD #1, 4 AS A$, 4 AS B$, 8 AS C1$, 8 AS D$, 10 AS E$
divides the buffer into segments,
where:
A$ points to byte 0 in the buffer:    [aaaa..............................]
B$ points to bytes 4 in the buffer:   [....bbbb..........................]
C1$ points to bytes 8 in the buffer: [........cccccccc..................]
D$ points to bytes 16 in the buffer: [................dddddddd..........]
E$ points to bytes 24 in the buffer: [........................eeeeeeeeee]

Unfortunately, the buffer is malloc'd else where.
When "free" is called (via clear), Clear indiscriminately attempts to "free" individual segments of the buffer.
Which it can't do.
Huh!

Now, I need to develop a work-around.

Steve

SteveA

  • Guest
Re: BxbAsm
« Reply #317 on: May 24, 2012, 02:11:09 PM »
James,
Okay, I've got it figured out, (I think).
The solution was, to not "free" (clear) the strings associated with the I/O buffer, but, to simply zero them out when they are no longer needed.
This required inventing another keyword, but, I see no other way of doing it.
Since the keywords FIELD and LSET/RSET directly pertain to the buffer and associated string names, I figured it was going to either be UNFIELD or UNSET.
So I decided on UNSET.
Here is an example of it's usage:
Code: [Select]
    FIELD #1, 4 AS A$, 4 AS B$, 8 AS D$, 10 AS E$
        LSET A$ = MKI$(dz)
        LSET B$ = MKI$(cz%)
        LSET D$ = MKD$(az#)
        RSET E$ = w$
        PUT 1, rec
    CLOSE 1
    UNSET A$, B$, D$, E$
    CLEAR


UNSET must be used after CLOSE and prior to a CLEAR command.

Here is what that snippet of asm code looks like:
Code: [Select]
  mov  eax, 0
  call closeafile
  mov  A, 0 ; release string from I/O buffer
  mov  B, 0 ; release string from I/O buffer
  mov  D, 0 ; release string from I/O buffer
  mov  E, 0 ; release string from I/O buffer
; --------------------------------------------------
  call clear_allvars


I have attached the new sources and executable.

Thanks,
Steve

Offline John

  • Forum Support / SB Dev
  • Posts: 3597
    • ScriptBasic Open Source Project
Re: BxbAsm
« Reply #318 on: May 24, 2012, 02:57:04 PM »
Quote
So I decided on UNSET.

undef might work as well.

jcfuller

  • Guest
Re: BxbAsm
« Reply #319 on: May 25, 2012, 03:11:13 AM »
Steve,
  Don't I also need the new (changed) library sources as it still fails with test48.


James

jcfuller

  • Guest
Re: BxbAsm
« Reply #320 on: May 25, 2012, 03:35:25 AM »
Never mind! tried it before my second cup :)
All is fine.

James

SteveA

  • Guest
Re: BxbAsm
« Reply #321 on: May 25, 2012, 06:16:20 AM »
Never mind! tried it before my second cup :)
All is fine.

Okay.

I'm getting ready to install Linux.
I do have some questions, maybe John and Air can weigh in on this too.

I'd like to setup minimal partitions (disk size) for more than one version of Linux.
I assume you can do that and select which OS you want to boot from.
I know you used to be able to do that with Windows: Win-95::Win-98::OS2.

I'd like to be able to test bxbasm on various popular versions.
I assume Ubuntu is a given.
What other flavors should I also consider ?
I don't need to set up a Linux server, at this time, so just basic OS's.

Thanks,
Steve


jcfuller

  • Guest
Re: BxbAsm
« Reply #322 on: May 25, 2012, 07:22:21 AM »
Steve,
  A lot of Ubuntu users are jumping ship because of the Unity interface. I switched (not because of Unity) to Linux Mint (12). I see there is a (13) out but I'm not sure at this juncture if I'll upgrade.

  Another alternative is VirtualBox. It's a lot easier to try different OS's. You can even install XP along with several different flavors of 'nix.

James

jcfuller

  • Guest
Re: BxbAsm
« Reply #323 on: May 25, 2012, 07:52:44 AM »
Steve,
Another plus for VirtualBox is you can set up drives that can be shared. Dual booting can be a real pain when you are developing an app for windows and Linux with no easy way to share code.
I don't dual boot anymore at all (well I don't have to with all the boxes I have). I do have one system with Win7 and Virtualbox which has several XP configs and 5 different Linux setups. All can share data with the main win7 system.

James

Offline AIR

  • BASIC Developer
  • Posts: 932
  • Coder
Re: BxbAsm
« Reply #324 on: May 25, 2012, 08:29:35 AM »
Steve,

As James mentioned, virtualization is the way to go here.  The three main reasons are:

1- You don't have to mess around with multi-boot/partitioning and associated headaches
2- You can have multiple virtual machines running simultaneously along with your core os (depending on system and resources)
3- Most valuable reason:  Snapshots.  You can take a snapshot of an OS before any changes, and revert easily if those changes mess things up.

Several years ago when I was working on porting Hotbasic to Linux, I used the Distrowatch site to determine which Linux distributions I should use to check the port against.  I continued that approach when I worked on the various BCX ports. 

As of this morning, the top 3 Linux distributions listed on Distrowatch are Mint, Ubuntu, and Fedora.  I would also recommend a Debian install, since it's the Grand-daddy of Ubuntu and the dozens of Ubuntu derivatives.

Two more things I should mention:  If you have a 64bit machine, you can virtualize both 32 and 64 bit Linux versions, which if you have the space I highly recommend because of the differences in library locations between the two.  Lastly, if space becomes a concern you can simply archive the virtual machines to external storage to clear up drive space.

A.

SteveA

  • Guest
Re: BxbAsm
« Reply #325 on: May 25, 2012, 10:03:26 AM »
As James mentioned, virtualization is the way to go here.

Thanks for your advice, James and Armando.

Quote
If you have a 64bit machine, you can virtualize both 32 and 64 bit Linux versions, which if you have the space I highly recommend because of the differences in library locations between the two. 
Lastly, if space becomes a concern you can simply archive the virtual machines to external storage to clear up drive space.

Okay, my machine is 64-bit and has a 500 GB drive, with only Win-7 installed.
So space is no major issue.
Let's say I want all three (or four) of those distros, (VM), how do I get started ?
What do I need to download ?

Yesterday, after reading an article, I downloaded "GParted-Live":
http://gparted.sourceforge.net/livecd.php

supposed to be a tool that helps linux-partition the drive.

I have links for Fedora, Ubuntu, Mint and Debian.

Steve

SteveA

  • Guest
Re: BxbAsm
« Reply #326 on: May 25, 2012, 10:09:18 AM »
undef might work as well.

Yes it would, but, I thought it might confuse people who have used 'undef' in other languages.
While deciding, I looked through my BASIC Reference Manual, searching for either a keyword that might fit or making sure I wasn't using  one that is already in use for some other purpose.

I'm still open to suggestion.
As far as I'm concerned, "UNSET" is only an expedient, waiting for something better.

Offline John

  • Forum Support / SB Dev
  • Posts: 3597
    • ScriptBasic Open Source Project
Re: BxbAsm
« Reply #327 on: May 25, 2012, 12:02:43 PM »
Quote
Yes it would, but, I thought it might confuse people who have used 'undef' in other languages.

That's why they call it Traditional BASIC;)

jcfuller

  • Guest
Re: BxbAsm
« Reply #328 on: May 25, 2012, 01:03:59 PM »
Steve,
  You won't need any partitioning software if you choose VirtualBox.
First get and install VitrualBox. Take the time to really give the instructions a good read.
https://www.virtualbox.org/

Then go to Distrowatch ( http://distrowatch.com/ )and check out the Rankings.
I'm going to check out both new Linux Mint 13 versions.

A word of warning re 32/64. If you opt for 64 you will also have to find and install all the needed 32bit libraries. For now I think 32 bit is in order especially as all your jwasm code is 32bit. I don't know how well versed you are in 64asm??? or even if you intend to expand Bxbasm
to 64bit???

James

SteveA

  • Guest
Re: BxbAsm
« Reply #329 on: May 25, 2012, 01:21:53 PM »
You won't need any partitioning software if you choose VirtualBox.
First get and install VitrualBox. Take the time to really give the instructions a good read.
https://www.virtualbox.org/

Okay, good to know that.
Thanks for the links.
I was googling "linux VM" and stubled across a forum that mentioned VirtualBox.

Quote
Then go to Distrowatch ( http://distrowatch.com/ )and check out the Rankings.

Right.

Quote
If you opt for 64 you will also have to find and install all the needed 32bit libraries.
For now I think 32 bit is in order especially as all your jwasm code is 32bit.
I don't know how well versed you are in 64asm??? or even if you intend to expand Bxbasm to 64bit???

Yeh, for the immediate, I will work with 32 bit.
I'm not ready for 64 bit asm.
I will work on that after we have a working 32 bit version running.
"Skin one cat at a time."

Thanks James,
Steve